Most rework is not caused by bad design. It is caused by somebody important seeing the work for the first time at the point where changing it means scrapping built engineering rather than redrawing a frame. The design was fine. The alignment was not.
Alignment is not consensus, and it is not a meeting. It is a standing habit: keep the direction visible, and go hunting for disagreement while it is still cheap. A quiet stakeholder is not an agreeing stakeholder — they are a stakeholder who has not looked yet.
Disagreement has a price, and the price rises with time. Caught in discovery it costs a conversation. Caught at design review it costs a round of rework. Caught after engineering has built it, it costs a release and a chunk of the team's goodwill.
Stakeholder Alignment
Start by naming them. Who can approve this, who can block it, and who merely has opinions — three different people needing three different amounts of your time. Write the list down. It is usually shorter and more surprising than you assumed.
Then brief the ones who can block, individually, before the big review. Keep them current between reviews too — two paragraphs on a regular beat. A senior person seeing the work for the first time in a room full of colleagues will find something to object to; that is what seniority looks like in a room. Shown it privately a week earlier, they arrive as a supporter.
Record decisions where anyone can find them: what was decided, who decided it, and why. Undocumented agreements get relitigated, usually by whoever was on holiday that week.
- 7 Steps for Effective Stakeholder Alignment — article
- [How to Manage Difficult Stakeholders [6 COMMON CHALLENGES]](https://www.youtube.com/watch?v=NaGhBpfZLzg) — video
Agile UX, Lean UX
Both approaches solve the same problem: a design phase that finishes before building starts produces a document that is already wrong by the time anyone opens it.
Agile UX means design runs in the same cadence as delivery. In practice that is working roughly a sprint ahead — validating next sprint's work while engineers build this sprint's — turning up to backlog refinement so estimates account for the interaction detail, not just the happy path, and reviewing what was built before anyone calls it done.
Lean UX changes what you produce. Instead of a specification, you write a hypothesis: we believe this change will cause this behaviour, and we will know we were wrong if this number does not move. Then you make the smallest artefact that tests it.
Neither is licence to skip research. They change when you do it, not whether.
- Lean UX & Agile: Study Guide — article
- Attributes of Effective Agile UX — video
- What is Lean UX? — video
Design Workshops & Sprints
Run one when a decision is genuinely stuck, or when several teams are carrying different pictures of the same problem. Do not run one because the calendar looked empty.
The classic five-day shape: map the problem, sketch solutions alone, decide on one, prototype it, put it in front of five users on the Friday. Compress it to two days if you must, but keep the shape.
Two rules carry most of the value. Sketch silently before discussing anything — open brainstorming converges reliably on whatever the most confident person said first. And have the person who can actually approve the direction present, at least for the deciding.
A workshop that ends with photographs of sticky notes and no named owner for the next step was a team-building exercise. It may even have been a good one.