Who should make the decision on the design project? One person making the decision doesn't mean one person has the final say

There are twelve people in the design group. Each of them can leave a comment like "Make it a bit more advanced here", and in the end, they often get a list of modifications that no one is truly responsible for. At the other extreme, the boss goes through all the pages alone, leaving no chance for decision-making regarding product processes, technical limitations, and user issues. A good mechanism is not about having everyone vote, but about having the right people provide input at the right nodes and having a clear role take on the final decision.

01 First, separate the four roles

One person can take on multiple roles, especially in a small team. But responsibilities must be clearly stated: who provides the information, who poses the risks, who integrates the feedback, and who makes the final decision. When the roles are unclear, the person in the highest position will be forced to handle all the details, and the design team cannot determine which opinion takes priority.

02 Decision-making power should change at different stages

03 The "final decision" should only occur at the explicit node

The design project requires stage locking. The requirements, information architecture, visual direction and final delivery should be confirmed respectively. When the previous stage is overturned later, the budget, cycle and impact should be re-evaluated. If the leader sees the visual direction for the first time in the later stage of development, the problem does not lie in the leader's many opinions, but in the failure of the review node arrangement.

The value of the decision-making mechanism does not lie in reducing opinions, but in ensuring that each opinion enters the project at the right time and for the right reason.

04 Feedback should not be written as aesthetic voting

Phrases like "Not sophisticated enough", "doesn't feel right", and "I prefer blue" cannot be directly executed. Effective feedback should at least consist of four parts: what problems were identified, which user or target was affected, what the basis was, and how high the priority was. The design team can propose solutions, but they cannot guess problems for the business side.

05 One review meeting will only address one type of issue

Stuffing processes, copywriting, visuals, technology and budget into the same meeting can easily cause discussions to keep switching. Requirements review addresses the scope, process review addresses tasks, visual review addresses directions, and development review addresses implementation. Before each meeting, clearly define the decisions to be made, available options, evidence and deadlines. After the meeting, record the conclusions and unresolved items.

06 When there is a conflict of opinions among multiple people, sort by basis rather than the number of positions

• First, determine whether the opinion belongs to business goals, user experience, brand, technology or compliance.
• Confirm whether there are approved principles, data or user evidence that can be directly adjudicated.
• If it is an irreversible and high-risk decision, add small-scale verification or technical experiments.
• If it is only a low-risk preference, the authorized final decision-maker will choose not to further expand the meeting.
• Record the abandoned plans and reasons to prevent the same argument from recurring in the next round.

07 Establish a one-page decision-making record to avoid repeated meetings on the same issue

After each stage is confirmed, the decision should be written into a traceable record on one page: what was decided, what the basis was, who approved it, which pages or tasks were affected, and which issues remain unresolved. It doesn't require a complex system and can be a table in the project document. The key point is that when someone later raises an opposing opinion, the team can first return to the original goal and evidence instead of starting the argument from preferences again.

08 Even small teams need the simplest decision table

Frequently Asked Questions

To what extent should the boss be involved?

The boss should confirm the business goals, major directions and key nodes, but does not need to be involved in every detail of each page. If a brand is highly dependent on the founder's expression, visual direction reviews can be added instead of leaving all opinions until the end.

Can design projects be voted on democratically?

Voting is suitable for collecting preferences but not for replacing professional decision-making. The information and responsibilities held by different roles vary, and ultimately, it should be determined based on the goals, evidence, and authorization mechanisms.

When opinions within the client are not unified, whose advice should the design party follow?

The contract and the kick-off meeting should clearly define the project leader and the final decision-maker. The design party can help sort out conflicts and impacts, but should not choose on its own which opinion within the client is "valid".

What should I do if the decision-maker is replaced at the last minute?

It is necessary to reconfirm the approved content, outstanding matters, changed authority and time impact. Don't assume that the new decision-maker accepts the previous direction, nor should you unconditionally restart all the work.