Framing a Design Process That Actually Works
Every design team knows the feeling: the project starts with a clear plan, but somewhere along the way it spirals into chaos. Deadlines slip, deliverables multiply, and the work becomes reactionary. The root cause is rarely a lack of effort — it’s usually a rigid process that doesn’t fit the realities of product development.
No single model works for every team, but four frameworks offer useful starting points. Each emphasizes different parts of the cycle, and together they cover the strengths and blind spots of the others.
The Four Models Worth Knowing
The Double Diamond is the most complete methodology for problem solving. A detailed walkthrough by Dan Nessler breaks the entire process into its individual stages, showing exactly how each one feeds into the next. It’s the most reliable approach when a complex problem needs structure from discovery through delivery.
The Triple Diamond extends that thinking by acknowledging that design work continues after a launch. Adam Gray argues that the double diamond model fails to capture the designer’s ongoing contribution throughout a product’s lifecycle, where ideas and prototypes evolve as the product is being built. The added flexibility improves planning by accounting for that post-launch loop.
For larger organizations, IBM’s Enterprise Design Thinking puts emphasis on design maturity and scale. It’s a practical model for making the case for user research, user-centricity, and fast low-fidelity prototyping, and for handing real ownership over to design teams across the organization.
The Hot Potato process is the simplest of the four. It removes the traditional hand-off between design and development entirely. Instead, the two functions continuously throw mockups and prototypes back and forth across the product’s whole lifetime, with the design phases growing or shrinking as needed. The approach is powered by uninterrupted collaboration — there's no "throwing it over the wall," just iteration between shared problem owners.
None of these models is meant to become a rigid rulebook. Rather, they act as frame of reference points that individual designers and teams can pull pieces from to create a process suited to their context.
Turning a Hybrid Process Loose
A realistic process starts early and prioritizes user input.
User research is never "done." The first step involves meeting users as soon as possible, mining all available data, speaking to customer support and service desk staff, reviewing known design debt, and combing through backlogs and previously rejected ideas. Org charts are useful too — they show who’s making decisions and where the silos are.
Only then does the design work begin. The output continues to be diagrams, spreadsheets, and documents long before any pixels hit a screen. Developers should be looped in during that period so they can start standing up the dev environment and flagging constraints early.
That groundwork keeps all stakeholders involved, especially those whose voice tends to get lost. The goal is to make design the bridge between business needs and user needs, not a taste-driven layer on top of either one.
The actual design work starts with a blank sheet of paper. Sketching covers concepts, customer journey maps, content boxes, and the known UI components. Naming workshops involving both designers and developers follow so that terminology aligns across product and code. From there development can build a prototype while design dedicates itself to deeper interface and interaction work.
Direction gets verified with customer journey maps and structured ideation exercises. Candidate ideas get prioritized — most frequently with the Kano model and an impact versus effort matrix, each involving developers, project managers, and stakeholders whenever possible. The judgment about what’s worthwhile is therefore shared among disciplines.
Making Success Measurable
Design KPIs get created to prevent hours of work being spent on the wrong concepts. Business objectives are chained onto KPI trees, and sign-off is gathered before visual design begins.
The workflow after sign-off is intentionally rapid and iterative. Hypotheses become low-fidelity mockups. Developers review and push back. New versions go to a working HTML and CSS implementation. Usability tests run to push top tasks toward an 80 percent success rate. This loop persists without starting over.
Measuring design quality becomes a system-level habit. Metrics to track now include task completion rates and times, error and recovery rates, accessibility, sustainability, performance, and, for B2B products, how long customers need to complete core tasks. Effort goes into shortening that duration.
That measurement data must be broadcast to the wider organization so design demonstrates its effect on business KPIs. People outside the design team need proof the process is evidence-driven and didn’t rely on hunches all along.
Ownership Beyond the Annotations
A process finally acquires focus when ownership is explicit. The search team gets measured by how well the top 100 queries perform over a quarter. Content publishers own the upkeep of what they ship — they’re expected to refresh, rewrite, archive, or delete content as it ages out of usefulness.
Once launched, the pace doesn’t slow down. Components and journeys head to the developers, there’s a moment of testing against users, and the project immediately improves inside the browser. KPI reporting feeds directly into the next iteration instead of being confined to a postmortem.
It may resemble organized chaos from a distance — and adaptiveness is exactly the point. The process exists to keep longer cycles and broader scope legible while design decisions become faster, more measurable, and less personal.
Teams should feel free to combine pieces of the four diamond and hot potato models, plus experiment beyond them. No one framing fits all contexts. The real promise is the mindset each one provides.
