Why Your Design Phase Keeps Blowing Up the Roadmap (And How to Fix It)
Katrina Ryl
Ever feel like your product roadmap is a beautifully timed train that constantly gets derailed by the "design bottleneck"? It’s a classic tech trap: features get the go-ahead, timelines get published, but an un-scoped design phase leads to rushed decisions, shifting mid-build requirements, and a staggering 26% of engineering time wasted on predictable rework. The truth is, your designers aren't slow, your planning process is just missing a shared baseline. Here is how a lightweight, structured Design Phase Delivery Framework can align your product, design, and engineering teams, stop late-stage scope creep, and finally protect your delivery timelines from going up in flames.
Date
If you work in product, you've seen this pattern. A feature gets the go-ahead. Engineering is briefed. A timeline is published. And then, somewhere between the kickoff and the sprint that was supposed to ship, design becomes the bottleneck. Decisions get rushed. Requirements shift mid-build. UX gets bolted on at the end. The team ships something that technically works but feels stitched together. Users notice. Stakeholders blame design. Design blames product management. Engineering quietly absorbs the rework.
This isn't a design problem. It's a planning problem. And it's solvable with a framework that treats design as a phase to be scoped, sized, and resourced. Not a soft activity that happens in the gaps.
The Real Cost of Underestimating Design
Most organisations don't measure the cost of rushed design until it's already buried in the dev cycle. Research on software rework consistently shows the same pattern. Teams routinely rebuild a significant slice of what they've shipped, and most leadership only sees the surface. One analysis found engineering teams rework around 26% of their code before release, costing mid-sized businesses millions per year, with development teams spending 30–50% of their time fixing defects and redoing work. Late-stage design changes cause roughly 90% of companies to delay some portion of their product launches, and in a McKinsey study, a six-month launch delay translated to a 33% drop in lifetime product profitability.
The cause is rarely bad designers or bad engineers. It's that the design phase was never properly scoped. There was no shared expectation of what design means before a story enters development. There was no estimation. There was no allocation of time.
What a Design Delivery Framework Actually Does
A Design Delivery Framework is a lightweight agreement between Product, Design, Engineering, and Business Analysis about how design work gets planned and delivered. It does four things:
Defines the phases design moves through before code is written.
Size the effort so Product can allocate time on the roadmap.
Clarifies who does what at each stage, so nothing falls through.
Builds in validation so assumptions get tested cheaply, before they're expensive.
It is not a methodology lock-in. It works alongside Agile, Lean, or Waterfall. It is not a gate that slows things down; it speeds things up by surfacing risk early, when changes cost hours instead of sprints.
The Four Phases: Double Diamond, Adapted for Delivery
The backbone of most modern design delivery frameworks is the Double Diamond, originally formalised by the UK Design Council in 2005. It maps the design process as two connected diamonds: the first focused on understanding the problem (Discover and Define), the second on creating the solution (Develop and Deliver). Each diamond alternates between divergent thinking (exploring broadly) and convergent thinking (narrowing to a decision).
Adapted for product delivery, the four phases become:
Discovery
Questioning and challenging the problem. The team rips the brief, decodes the pain points, runs research where needed, and gathers secondary insights. The temptation to skip this step and rely on past experience is exactly what produces rushed solutions later. Discovery is not about confirming a predetermined direction; it's about uncovering what's actually going on.
Define
Reviewing and analysing findings. Insights from discovery are clustered into themes. User needs and requirements are documented. Low-fidelity wireframes or prototypes start to visualise possible directions. The output of this phase is a clear, agreed problem statement that everyone can point at.
Ideate (Develop)
Generating and prototyping solutions. This is where the team explores how to solve the defined problem. Workshops, sketches, high-fidelity mockups, technical feasibility conversations with engineering, and breaking the work into user stories. Multiple solutions are tested before one is committed to.
Test and Prep (Deliver)
Validating and preparing for build. Solutions are validated with SMEs or users through moderated or unmoderated studies, or simple walkthroughs. Final assets are prepared. Definition of Ready (DOR) and requirements are written. The story is genuinely ready for engineering, not "we'll figure it out in the sprint."
This is iterative, not linear. Teams often loop back, testing reveals a problem the define phase missed, and ideation surfaces a question only more research can answer. That's the framework working as intended.
Sizing Design Effort with T-shirt Sizing
The single most useful planning tool to bolt onto this is T-shirt sizing (XS, S, M, L, XL). It's a lightweight relative-estimation technique used to gauge the complexity and effort of a piece of design work, well-suited to roadmap and release planning where detail is thin and the goal is direction, not exact dates.
A practical mapping:
Size | Type of work | Indicative effort |
|---|---|---|
XS | Minor feature improvement | 2–20 days |
S | Major feature improvement | 20–40 days |
M | New minor feature | 30+ days |
L | New major feature | 60+ days |
XL | New product | 3+ months |
These are not contracts. They are shared expectations. The point is to let Product Managers allocate roadmap time upfront before the team is already three sprints in and discovering that what looked like an "S" is actually an "L." T-shirt sizing also surfaces dependencies and forces honest conversations about scope before they become rework conversations later.
A few rules that make T-shirt sizing actually work:
Size with the right people in the room. Product, design, engineering lead, and a BA if you have one. Sizing in isolation produces fiction.
Don't size more than a quarter ahead. Annual roadmaps sized to feature level become wishful thinking by Q2.
If you're stuck between two sizes for more than a few minutes, pick the larger one and move on. You can refine later.
RACI: the Unglamorous Part that Prevents Most Arguments
Most of the friction in cross-functional delivery comes from unclear ownership. Who decides? Who does the work? Who needs to be in the room? Who needs to know? A RACI matrix answers all four:
R — Responsible. Does the work.
A — Accountable. Owns the outcome and makes the final call. Only one person per task.
C — Consulted. Provides input before the work is done.
I — Informed. Needs to be kept in the loop on progress.
Applied across the four phases, the RACI for a typical mid-sized feature looks roughly like this:
Discovery: PM accountable, BA responsible, UX consulted, Lead Dev informed.
Define: PM accountable, BA responsible, UX consulted, Lead Dev consulted.
Ideate: UX accountable, BA and Lead Dev responsible, PM informed.
Test & Prep: BA accountable, UX responsible, PM and Lead Dev consulted.
The specifics will shift by size. The bigger work pulls UX into accountability earlier, and the smaller work keeps it lighter. The principle holds: every phase has exactly one accountable role, and everyone else knows where they fit.
How to Actually Roll This Out
If you're introducing this in an organisation that doesn't have it yet, don't try to mandate it everywhere on day one. A few practical steps:
Start with one team and one upcoming feature
Pick something medium-sized and run it through the framework end-to-end. Treat the first run as a learning exercise, not a compliance check.
Get Product to own the sizing process.
PMs are accountable for roadmap planning, so they should own the T-shirt sizing conversation — but in collaboration with UX and engineering. If PMs size in isolation, the framework is dead on arrival.
Make the RACI visible
Stick it in your Confluence space, your project template, wherever your team actually looks. RACI that lives in a slide deck no one opens is RACI that doesn't exist.
Allow the framework to evolve
The first version will be wrong in some ways. Run it for a quarter, retro on what didn't fit, and adjust. A framework that can't evolve is just bureaucracy.
Prioritise the fastest, cheapest way to validate
This is the most important principle in the whole thing. Every phase should be looking for the cheapest possible way to test the next assumption. Sketches before wireframes, wireframes before high-fi, prototypes before code. The further down the chain a wrong assumption gets caught, the more it costs.
Below is an example of this framework.
So, What's the Point?
A Design Delivery Framework isn't about turning design into a process people fill out. It's about giving design the same planning rigour that engineering already gets. It gets sized, scoped, owned, and sequenced. When that happens, design stops being the thing that blows up the roadmap and starts being the thing that protects it.
The version that works for your organisation will not be identical to anyone else's. But the bones of it include the four phases, size effort, clear ownership, and cheap validation are portable. Start with those, and iterate from there.
Sources
Design Council — Framework for Innovation: the Double Diamond. The original source for the Discover / Define / Develop / Deliver model. https://www.designcouncil.org.uk/resources/framework-for-innovation/
Design Council — The Double Diamond. Licensed under CC BY 4.0. https://www.designcouncil.org.uk/resources/the-double-diamond/
Easy Agile — Agile Estimation Techniques: A Deep Dive Into T-Shirt Sizing. https://www.easyagile.com/blog/agile-estimation-techniques
Asana — T-Shirt Sizing: Agile Estimation & Capacity Planning (2026). https://asana.com/resources/t-shirt-sizing
Clutch.co — How to Use T-Shirt Sizing for Capacity Planning. https://clutch.co/resources/how-to-use-t-shirt-sizing-for-capacity-planning
Maze — The Double Diamond Process: From Problems to Solutions. https://maze.co/blog/double-diamond-design-process/
UXPin — Double Diamond Design Process: The Complete Guide for Product Teams (2026). https://www.uxpin.com/studio/blog/double-diamond-design-process/
Capicua — How To Reduce Cost of Rework In Software Development. Source for the 26% rework figure, ~$4.7M annual cost, and 30–50% time-on-defects statistic. https://www.capicua.com/blog/cost-of-rework-software-development
CoLab — Rework is No Longer a Necessary Evil. Source for the 90% product launch delay figure and the McKinsey 33% lifetime profitability finding. https://www.colabsoftware.com/research/rework-is-no-longer-a-necessary-evil
Zero Blockers — The Hidden Costs of Big Design Up Front (And How to Avoid Them). Source for the Microsoft 33% harmful-features finding. https://blog.zeroblockers.com/p/the-hidden-costs-of-big-design-up-front-and-how-to-avoid-them
Product School — Product Management Frameworks & How Top Companies Use Them. Background on Stage-Gate, Double Diamond, and Agile frameworks. https://productschool.com/blog/product-fundamentals/product-management-frameworks
UXPin Blog — Product Development and Design: Tips to Improve Collaboration Between Designers and Developers. Reference for the Segment discovery/delivery model. https://www.uxpin.com/studio/blog/product-development-and-design/
More Ideas
Thoughts, concepts, and ongoing explorations
