Why "the process" needs a new shape
Every UX education programme teaches the same two diagrams. The Double Diamond, with its discover-define-develop-deliver arcs. And some version of Design Thinking, usually shown as a circular loop with empathise, define, ideate, prototype, test. Both are correct in outline. Neither describes what actually happens on a Wednesday afternoon in a product team that has six engineers, two designers, a PM, three stakeholders, and a deadline that moved last week.
The textbook diagrams have a particular failure mode: they make the process look smoother, more sequential and more research-led than it really is. In practice the work is iterative within each stage, the stages overlap, the team revisits earlier stages mid-build, and the time allocation is heavily skewed toward decision-work and stakeholder alignment rather than research or production.
This article uses a different frame: five operational stages a team passes through (sometimes twice, sometimes in odd orders) to turn a vague problem into a shipped product change. It is closer to what senior practitioners actually do. It is also closer to how AI-augmented teams in 2026 are choosing to sequence their work.
The five operational stages
Each stage is defined by the question the team is trying to answer, not the activity the team is performing. That distinction matters: it's the activity-focused framings (interviews! prototyping! testing!) that produce process theatre. Question-focused framings produce decisions.
What each stage asks
- Sense. Is there a real problem here? Strong enough to spend a team's time on?
- Frame. What exactly is the problem, stated in language everyone in the team understands?
- Explore. What are the candidate solutions, and what would each one mean for users and the business?
- Decide. Which solution do we ship, and what trade-offs are we accepting?
- Ship. How do we get this into production without losing the thing that made it good?
Activities (interviews, workshops, prototypes, usability tests, design QA) live inside the stages. The discipline is to choose activities that answer the stage's question, not activities that perform UX rigour for its own sake.
01 · Sense — is the problem real?
Most product work starts in one of three ways. A stakeholder spots an anomaly in the analytics. A user complaint surfaces in a support ticket. A leader has a feeling, based on something they read or a competitor they saw. Each of these is a signal, not yet a problem. The Sense stage exists to decide whether the signal is worth the team's attention.
The work in Sense is fast and unglamorous. Pull the relevant analytics. Read the support tickets adjacent to the signal. Walk through the relevant flow yourself. Ask three people in the team if they've heard the same thing from a different angle. Two outcomes are possible: the signal is corroborated and the work proceeds to Frame, or the signal is not corroborated and the team de-prioritises politely. The mistake is to skip Sense and immediately commit a sprint to a problem that turns out not to exist at scale.
In 2026 this stage benefits significantly from AI-assisted scanning of analytics anomalies, support ticket clustering, and competitor surface review. A two-day Sense investigation in 2022 takes half a day in 2026. The judgement of whether to proceed remains human.
02 · Frame — what exactly is the problem?
Frame is the highest-leverage stage in the process and the one most teams shortchange. The goal: produce a one-paragraph problem statement that everyone in the team can repeat back accurately. If they can't, the framing isn't done.
A good problem statement names three things: who is affected, what specifically goes wrong, and what changes if it's solved. "Users abandon at checkout step three at twice the rate of step two; we believe the field count is the cause; if we halve the fields, we estimate a 6–10 percent lift in completion." That's a frame. "Improve the checkout experience" is not.
Most framing failures are political, not analytical. A PM has a hypothesis, a designer has a concern, an engineer has a constraint, and the resulting framing is a compromise that satisfies everyone and commits to nothing. The senior practitioner's job in Frame is to push back on the compromise version and produce the version that the team can actually solve.
Spending an extra day in Frame routinely saves two weeks in Ship. The two-week saving is invisible (because it's a problem you avoided rather than fixed); the extra day is visible. So Frame is the stage stakeholders most often try to compress. Senior practitioners learn to defend it.
03 · Explore — what are the candidate solutions?
Explore is where most textbook UX content focuses: research, ideation, divergent thinking. Modern operational reality is more constrained. Most product teams have a small number of viable candidate solutions, and the work in Explore is to articulate each one specifically, identify what evidence would adjudicate between them, and acquire that evidence.
Three patterns of evidence dominate Explore:
- Quantitative. Analytics segmentation, A/B history, behavioural data. Tells you what users actually do across the population.
- Qualitative. Interviews, usability tests, contextual enquiry. Tells you why a behaviour happens for a specific user.
- Comparative. Competitive review, design audit, heuristic evaluation. Tells you what the candidate solutions look like in deployed form elsewhere.
The senior practitioner's discipline is to pick the cheapest evidence that adjudicates the candidate solutions, not the most prestigious. A two-day competitive review often beats a four-week diary study for an Explore decision that needs to happen this sprint. The full operational view of method selection sits in UX research methods.
04 · Decide — which solution ships?
Decide is the stage that distinguishes the senior practitioner from the mid one. The work: turn the candidates and evidence from Explore into a recommendation the team can act on, with the trade-offs named explicitly and the reasoning documented.
A good Decide deliverable answers four questions. What do we recommend? What did we consider and reject, and why? What evidence supports the recommendation? What are we accepting as a trade-off, and what would change our mind? When a team can name all four they can ship the decision through stakeholder review without losing the thread. When they can only name the recommendation, the decision unravels the first time anyone asks "but what about X?"
The discipline in Decide is to be specific. "We will reduce form fields from 14 to 7" is a decision. "We will simplify the form" is not. Specificity is the gift you give the engineering team; vagueness is the bill they pay later.
05 · Ship — getting it into production
Ship is where the design meets the build, the stakeholders meet the design, and the design meets the user. Three sub-stages live inside it:
Production design. Turning the decision into spec the engineering team can build from. Component selection, edge cases, error states, content, accessibility. This is where the design hits a real screen for the first time. AI is increasingly useful here for first-pass production but the judgement layer (edge cases, content polish, accessibility nuance) remains human.
Stakeholder approval. Walking the design through the review chain — PM, engineering lead, legal/compliance if relevant, executive sign-off if scoped that high. The work in this sub-stage is communication, not design. A well-framed Decide artefact reduces stakeholder approval from weeks to days.
Design QA during build. Most teams treat this as optional. Most teams ship products with detail bugs they could have caught for the cost of a designer pairing with engineering for an afternoon a week. The senior practitioner's discipline is to be present in the build, not just the design.
After Ship, the work loops: a new Sense signal arrives (sometimes from the change you just shipped) and the cycle begins again.
What it looks like sprint to sprint
The marketing version of the UX process suggests a team moves cleanly from stage to stage in sequence. The operational reality is that any week, a team is working in multiple stages on different problems. A useful weekly rhythm for a small product team:
- Monday. Reset on what's in each stage. Identify the highest-risk decision the team will make this week and what evidence is needed for it.
- Tuesday–Wednesday. The bulk of cross-stage work: research synthesis, design production, stakeholder conversations. Pair-work and unblocking happens here.
- Thursday. Decision day. The week's framing decisions, design choices and Ship sign-offs are surfaced and resolved.
- Friday. Communication and prep. The week's outputs go to stakeholders. Next week's work is teed up.
The week shape is more important than the stage shape. Teams that have a predictable weekly cadence for decision-making ship faster than teams that have a beautifully diagrammed process but no shared rhythm for resolving disagreements.
Where AI fits per stage
By 2026, AI has reshaped what each stage costs in time and effort. The pattern is consistent: AI accelerates the mechanical layer of each stage; the senior judgement layer in each stage remains human.
What accelerates, what doesn't
Sense. AI accelerates: scanning analytics anomalies, clustering support tickets, summarising competitor surfaces. Human keeps: deciding whether the signal is worth the team's time.
Frame. AI accelerates: drafting problem statements from mixed inputs. Human keeps: pushing back on political compromise framings, ensuring the frame is solvable.
Explore. AI accelerates: coding interview transcripts, clustering themes, generating first-pass synthesis. Human keeps: recognising what an interviewee isn't saying, choosing which evidence pattern to chase.
Decide. AI accelerates: scoring options against criteria, drafting decision memos, summarising rationale. Human keeps: naming the trade-offs honestly, defending the recommendation in the room.
Ship. AI accelerates: first-pass production design, asset generation, content variants, design QA notes. Human keeps: edge cases, accessibility nuance, brand and content polish, real stakeholder communication.
The full operational guide on AI's place in UX work sits in the cluster: AI for UX designers and the authority anchor what AI should not replace in UX.
Process failure modes
Five patterns recur in weak UX processes. Each one is fixable but most teams need to be told they're doing it.
- Skipping Frame. Going from Sense straight to Ship via a few wireframes. The team produces a design quickly and slowly discovers it doesn't solve the right problem. By far the most common failure mode.
- Research after commit. Running usability tests on a design that has already been approved. The findings cannot be acted on because the design is already in build. The research wasn't bad; it was late. Lateness is a process failure.
- Over-investing in Explore. Six weeks of interviews, three weeks of synthesis, one week of Decide, no Ship. Beautiful research artefacts; no product change. The senior practitioner's discipline is to budget time toward Decide and Ship, not away from them.
- Prototype-as-trophy. Producing a prototype, presenting it to stakeholders, never testing it with users. The prototype was an output, not an input to a decision. Every prototype should have a test it is going to run.
- Closing the loop at design approval. Treating design sign-off as the end of UX involvement. The build introduces drift; the drift compounds; the shipped product looks materially worse than the approved design. Design QA during the build is non-optional in mature teams.
Scaling: solo, 5, 50
The five stages are the same regardless of team size. What changes is who holds each stage and how heavyweight the artefacts are.
Solo designer (or small team under 5). One person holds all five stages, often in compressed time. Sense and Frame happen in conversations rather than artefacts. Explore is lighter on dedicated research and heavier on analytics and quick competitive review. Decide is documented in a one-page memo rather than a deck. Ship integrates design QA naturally because the same person is doing the design and watching the build.
Mid-team (5–15 designers). Stages start to be held by different people. A researcher might own Sense and Explore; a designer holds Frame, Decide and Ship; a design lead holds the seams between them. Artefacts get more formal because handoffs need to be readable by people who weren't in the original conversation.
Enterprise (50+ designers). Stages become specialised. Research teams own Sense, Frame and most of Explore. Interaction designers own Ship production. Content designers, accessibility specialists and design system maintainers all hold pieces of the work. Design leadership manages the political layer that emerges when this many people care about the same artefact. Process gets heavier; weekly cadence still matters more than diagram fidelity.
The pattern: as team size grows, the stages don't change but the social and political overhead of moving between them does. Process maturity at scale is mostly about reducing that overhead.
Artefacts that earn their place
A short list of artefacts that consistently earn their place in modern UX work. Every other artefact should be challenged.
- Problem statement. One paragraph. Names who's affected, what goes wrong, what changes if it's solved. Produced in Frame, referenced in every subsequent stage.
- Decision memo. Two pages. What was recommended, what was rejected and why, what evidence supports the recommendation, what trade-offs were accepted. Produced in Decide.
- Annotated design. Production-ready Figma frames with edge cases, error states, content and accessibility notes. Produced in Ship.
- Stakeholder playback. A 10-slide deck that walks the work through review. Lives outside the design tool; written for the people who weren't in the room. Produced in Ship.
- Audit findings. Where the work touches a wider product surface, an audit-style finding doc. The audit template covers the structure.
Almost every other artefact (personas without anchoring, journey maps that nobody uses, brainstorm output, sticky-note photos) is process theatre. Produce them if they help the team think; cut them the moment they stop earning their place.
Frequently asked questions
What is the UX design process?
The operational sequence a team follows to turn a vague problem into a working product feature. Five stages cover what modern teams do: Sense (notice the problem is real), Frame (state it specifically), Explore (research and ideate), Decide (synthesise and prioritise), Ship (design, test, deliver). The textbook frameworks like the Double Diamond simplify this; the operational reality is messier, more iterative and more commercially constrained.
Is the Double Diamond still relevant?
As a teaching tool, yes; as an operational guide, mostly no. The Double Diamond accurately describes the divergent–convergent dynamic of design work. It doesn't describe how modern product teams sequence the work, allocate time or hand off between stages. In 2026 most senior practitioners use the Double Diamond as a vocabulary, not a process.
How long does the UX design process take?
A scoped feature in a working product runs two to eight weeks. A genuinely new product cycle runs three to six months. A redesign of a mature product runs six to twelve months. Stakeholders almost always assume the process is faster than it is; the bottleneck is rarely production but synthesis, decision and stakeholder alignment.
Where does AI fit in the UX design process?
AI accelerates the mechanical layer of each stage. Drafting problem statements, coding interview transcripts, scoring options, producing first-pass design, generating content variants. What AI doesn't do is decide which option matters, defend recommendations to stakeholders, or recognise the signal in a quiet pause during an interview. Senior designers in 2026 use AI as an accelerator on judgement, not a replacement for it.
What are the most common UX process failures?
Five recur. Skipping framing and going straight to production. Running research after the design is already committed. Over-investing in discovery and starving decision and trade-off work. Treating prototypes as artefacts to admire rather than tests to run. Closing the process at design approval and ignoring design QA during the build.
Do small teams need a UX design process?
Yes, in a different shape than a 50-designer org. Small teams compress the five stages into shorter cycles, share the work across the whole team rather than handing off, and rely on lightweight artefacts. The process discipline matters more in small teams because there's no senior reviewer catching the framing mistakes. The shape changes; the underlying stages don't.