A design retrospective is the first thing to get cut when a team is already racing into the next project the day after wrap. But a project that ends without one tends to repeat the same mistakes a few months later, followed by the familiar line: “didn’t we run into this exact thing last time too?”
1. Why Retrospectives Disappear
Retrospectives usually get dropped because of time pressure. The moment a project wraps, the next one is already queued up, and revisiting the last one loses out to that priority. If the outcome turned out well, there’s a feeling that nothing needs re-litigating; if it turned out badly, reopening the story is simply uncomfortable. Neither instinct is really about the retrospective itself.
The gap grows more visible the more an organization runs client projects back to back. A scheduling headache hit on Project A gets repeated, almost identically, on Project B a few months later — and if no one who worked on both projects is still around, even that repetition goes completely unnoticed. This is exactly why a design retrospective needs to live as an organizational record, not a personal memory. Even if a team member leaves or rotates onto a different project, the retrospective record stays behind so the next person doesn’t repeat the same missteps.
2. Outcome Retros vs. Process Retros
It helps to run retrospectives along two separate tracks. An outcome retro looks at how closely the final screen matched the original goal, and how much of what surfaced in usability testing got resolved before launch. A process retro looks at why the schedule slipped, whether critique sessions actually helped, and what kept coming up as a recurring friction point in client communication.
Outcome Retro
Did the final screen match the goal, and were the issues usability testing surfaced resolved before launch?
Process Retro
Why did the schedule slip, did critique sessions actually help, and what problem kept repeating in client communication?
3. Turning a Retro Into an Actual Record
A retrospective doesn’t need a heavyweight document. A short format — three things that went well, three that didn’t, three to do differently next time — is enough. Most of the formats widely used in agile retrospectives are built on some version of this same simple structure.
What matters most is that the record actually gets reopened when the next project kicks off. It’s most accessible sitting inside the project folder of whatever document tool the team already uses.
Every participant writes their own notes alone first, for five minutes. Fixing the speaking order in advance tends to make people simply agree with whoever goes first.
Each person walks through what they wrote and shares it. Sharing only after writing alone first pulls out more honest accounts.
The facilitator narrows the discussion with concrete, pre-prepared questions rather than vague impressions, which pulls out more actionable answers.
The retro notes get attached directly to the next project’s kickoff materials, and get checked again at the following retro to confirm they were actually followed.
💡 Pro tip — If every retro ends on “great work, everyone,” have the facilitator prepare one concrete question in advance, like “what task ran twice as long as we expected on this project?” That alone tends to surface far more useful answers.
4. What’s Different About a Design Retro
Most teams run retros purely from a project-management angle — how late the schedule ran, whether resources were allocated well — while a design-specific retro on the final screen and decisions gets skipped. A design retro goes one layer deeper: it maps out concretely which design decisions actually solved real user problems, and which plan ended up drifting from its original hypothesis.
A Typical Project Retro
Stops at schedule- and resource-level conclusions, like “the timeline slipped.”
A Design Retro
Digs into why direction changed at the third round of concepts, and whether the original problem statement was actually vague.
Do Small Projects Need Retros Too?
It’s easy to assume a short project has nothing worth reviewing. But the smaller the scope, the less overhead a retro carries, and the easier it is to actually run one. Even a tight 30-minute design retro is enough if it leaves behind one thing that went well and one that didn’t. Stack up design retros from small projects and you’ll often spot more patterns than you would from a single retro on one large project — small recurring mistakes are easy to miss on a big project, but they stand out clearly once several short retros are lined up side by side.
Before starting a retro, check these:
- Was retro time set aside within one to two weeks of wrap?
- Was the outcome retro run separately from the process retro?
- Were concrete questions prepared ahead of time?
- Is the record kept somewhere the team will actually revisit?
- Did anyone confirm whether last time’s takeaways were actually applied to this project?
- Was the retro record actually attached to the next project’s kickoff materials?
Closing thoughts
A design retro isn’t a ceremony for wrapping up a project — it’s prep work that reduces mistakes on the next one. If you have a project ending soon, start simply by writing down three things that went well and three that didn’t.
Design Daily Life · Notes on design, daily
한국에 온 외국인 친구가 있나요? 메뉴 번역·택시 요금·약국 카드가 한 앱에 있는 K-OREA를 알려 주세요.
Visiting Korea? K-OREA puts menu scanning, taxi fare guidance and a pharmacy card in one app. Get it on the App Store.