Design problems in product teams often originate outside the design itself. Three versions of one button, a colour debate reopened every release or a flow quietly changed during development all reflect how decisions are made. This article describes a manageable approach to design decisions.
Who owns the decision? #
The first question is authority: who has the final say on a screen? If the answer is “everyone”, the loudest voice decides. If it is “nobody”, decisions happen during development, under time pressure and without a record.
Ownership does not mean excluding other views. Product managers, developers and business teams contribute; one person responsible for design consistency decides and records the reason. Whether that is a senior designer, a design lead or an external team matters less than having the role clearly defined.
Not every decision carries the same weight #
Putting every decision through the same process slows teams down. Two groups are useful.
- Easily reversible decisions: wording, a card layout or an icon. Make them quickly, monitor after release and change if needed.
- Hard-to-reverse decisions: navigation, information architecture, design system foundations and product voice. These need more evidence, broader input and a written rationale.
Teams often spend time treating the first group with the seriousness of the second. Making the distinction early shortens meetings.
A single source of truth #
For a decision to hold, everyone needs to see the same thing in the same place. Which design file is current? Where is the correct component? Which version is approved? The answers should point to a location, not a person.
A design system meets this need. Colours, spacing, components and usage rules are agreed once and read from the same source in design and code. We discuss when a system is useful, and when it becomes overhead, in our guide to design systems. Even without a system, file organisation, naming and the rule for identifying the current version should be documented.
A rhythm of reviews #
Good decisions require early, regular visibility of design. A weekly critique can provide it. Its purpose is not to collect approval but to test whether the design serves the goal. The presenter explains the problem and the input they need. Feedback takes the form of questions and observations, not imposed solutions.
Without a rhythm, design is seen too late or everyone comments separately, leaving the designer between conflicting opinions.
Decision records #
Record three things for important decisions: what was decided, which options were rejected and why. A few lines are enough.
The record serves two purposes. New team members do not reopen the same debate. And when circumstances change, the original assumptions are visible, so the decision can be revised deliberately.
Handoff and beyond #
A design decision holds only if it is implemented in code. Handoff includes states, limits and behavioural rules, not just screens. Before release, the implementation is compared with the design and differences become tasks.
Skip that final step and decisions quietly change during development. We examine where this happens in moving from Figma to a working product.
When several teams work on one product #
If one agency handles brand communication, another team the website, an internal team the app and a software partner the internal tools, decisions can fragment. Visual language, user experience and implementation each move in a different direction.
What is missing is not production capacity, but direction. In our Design Leadership service, we do not replace internal teams or production partners. We bring brand, interface and experience decisions into a shared framework, establishing quality standards and a review schedule. Where a live product also needs ongoing design production, this role works alongside Product Design Support.
Where to start #
You do not need to establish everything in one day. For most teams, these three steps are enough to begin:
- Name the decision owner and identify which decisions need a written rationale.
- Identify the current design file and single component source.
- Schedule a weekly review and record important decisions in a few lines.
Once these foundations are in place, a design system, quality checks and cross-team coordination can build on them.
Sources #
- Design Critiques: Encourage a Positive Culture to Improve Products, Nielsen Norman Group; organising design critique sessions
- Design Systems 101, Nielsen Norman Group; the design system as a shared source of decisions
- Shape Up, Basecamp; scope and decision ownership
