The short answer
Most practitioners believe design decisions are finalised in design reviews — the meeting where work is presented, feedback is given, and changes are agreed. Design reviews are the most visible decision point, but they are rarely where the most consequential decisions are made. Those decisions happen in conversations that precede the review, in sprint planning sessions that fragment journeys the designer conceived as whole, in brief exchanges between developers and stakeholders when a constraint appears during build, and in steering groups where design consequences go unnamed because no designer is present. Understanding where decisions actually happen changes where influence needs to be invested.
Why the design review feels like the decision point
The design review has the formal properties of a decision point. Work is presented, feedback is solicited, and changes are noted. There is often a record; notes, actions, or a shared document. For a practitioner, it is the moment when the work is most visible and the conversation is most explicitly about design.
But the design review is not where decisions are made, it is where decisions are confirmed, challenged, or ratified — decisions that have typically already been shaped by earlier conversations and constrained by earlier commitments. The UX practitioner who arrives at a design review without having invested in the conversations that precede it is often arriving to defend a position that has already been undermined, or to propose something that has already been ruled out.
Where decisions are actually made
The decisions that most consequentially shape what gets built tend to happen in four places:
1. Pre-design scoping conversations
When a product manager and a delivery lead agree on scope, timeline, and constraints before the design process begins, they are making decisions about what design can and cannot address. If a designer is not present — and they often are not, because the conversation is framed as a planning conversation rather than a design conversation — those constraints arrive as given rather than as negotiable.
2. Sprint planning
When work is broken down into sprint tasks, journeys that a designer conceived as structurally connected can be fragmented into components that get implemented separately, by different developers, at different times. The structural reasoning that connected them — the user journey, the state transitions, the commitment escalation — is not visible in a task list. What gets built reflects the fragmentation rather than the original design.
3. Build-time exchanges between developers and stakeholders
When a constraint emerges during implementation, the quickest person to consult is often a nearby stakeholder rather than the designer. The resolution that gets made is pragmatic and immediate. It may be entirely reasonable given the information available. However, it is often wrong given the reasoning the designer holds but wasn’t present to contribute.
4. Governance meetings without design representation
Steering groups, programme boards, and commercial reviews make decisions about scope, priority, and trade-offs that have direct consequences for design. When no designer is in the room, those consequences go unnamed. Decisions that a designer would immediately recognise as structurally significant pass without comment because nobody present has the frame to notice them.
What this means for how practitioners operate
UX practitioners who understand where decisions are actually made shift their behaviour in consistent ways. They stop treating design reviews as the primary arena for influence and start treating them as one of several touchpoints — and not the most important one.
They invest in pre-design conversations, asking to be present or represented when scope and constraints are being set, and contributing reasoning about what different scoping decisions will produce in terms of user outcomes. They build relationships with the developers who make reactive decisions to problems during build, so those decisions draw on design reasoning rather than on what happens to be visible in the design artefact. They find ways to get design reasoning into governance meetings; through written materials, through a product manager who understands the design implications, through whatever route is available.
They also accept that they will not be in every room for every decision. The practical response to that is to make their reasoning available in places where it can be consulted when they are not present — in annotations, in decision rationale documents, in the relationships they have built with people who will be in the rooms they cannot reach.
Instead of asking how to make your design reviews more effective, ask which decisions are already being made before your work reaches the room, and who is making them.
Frequently asked questions
Why don’t design reviews produce design decisions?
Design reviews produce ratification of design decisions rather than their origination. By the time a design reaches a formal review, the constraints that will shape its implementation have typically been set in earlier conversations such as scoping discussions, sprint planning, stakeholder conversations. The review confirms or modifies a design within those existing constraints. A practitioner who has not invested in shaping those constraints will find the review’s freedom to be narrower than it appears.
Where do the most important design decisions get made?
The most consequential design decisions are made in pre-design scoping conversations, sprint planning sessions, build-time exchanges between developers and stakeholders, and governance meetings without design representation. These are the points where constraints are set, journeys are fragmented, pragmatic calls are made, and trade-offs are agreed — all without explicit design framing. The design review is where the residue of these decisions is presented as a design.
How can UX practitioners influence decisions they are not present for?
Influence over decisions made in your absence requires two things: relationships with the people who will be in the rooms you cannot reach, and reasoning that is embedded in the work itself rather than carried in your head. A developer who has your reasoning available will make different build-time calls than one who does not. A product manager who understands the design implications of a scoping decision will argue differently in a planning meeting. Influence that depends on your physical presence is fragile; influence embedded in materials and relationships is more durable.
How do you get design included in scope and planning conversations?
Getting design included in scope and planning conversations requires demonstrating that design input at that stage changes outcomes in ways that matter to the people running those conversations. This typically appears in terms of delivery risk, build complexity, or cost of late-stage corrections. This argument is more effective when you have a track record with those people than when it is being made for the first time. Credibility built in earlier, lower-stakes interactions is what earns a seat in conversations that were previously happening without you.