The UX Design Process: Steps, Methods and How It Works in Practice

If you search for "UX design process" you will find a lot of diagrams with five neat boxes and arrows between them. The reality is messier and more interesting than that.

The UX design process does have recognisable stages. Understanding them is essential if you are considering a career in UX design or trying to understand what UX designers actually do all day. But the stages do not run in a straight line, teams skip backwards constantly, and in an agile product team a full "cycle" might fit inside a two-week sprint.

This post explains what each stage involves, how they connect, and what working through them actually looks like on a real project.

Why process matters

Teams without a shared process produce inconsistent work. Two designers on the same team will approach a problem differently, make decisions for different reasons, and produce designs that conflict with each other and with what users actually need.

Process is not about following rules. It is about making sure that decisions are grounded in evidence, that the problem is understood before the solution is reached, and that the people who will use the product are involved before build begins rather than after.

The other reason process matters: it is what you are hired to bring to a team. Any reasonably competent person can learn a design tool. What takes longer to develop is the ability to run a research session, make sense of conflicting data, frame the right design problem, and know when a prototype is good enough to test.

The core stages

1. Discovery and scoping

Every project starts with a brief of some kind. A product manager has a problem they want solved. A client has a business goal. An executive has noticed a metric they want to change.

Discovery is the stage where you interrogate the brief before accepting it. What is the actual problem here? Whose problem is it? What constraints exist — technical, commercial, regulatory, time? What has already been tried?

This usually involves conversations with stakeholders: the people who commissioned the work, the people who will build it, and sometimes legal or compliance teams if the product touches sensitive areas. The output is a shared understanding of scope and goals, documented well enough that the team can refer back to it when decisions get contested later.

Skipping discovery is one of the most common mistakes junior designers make. It feels like a shortcut to get to the designing faster. It usually means redesigning things twice.

2. Research

Research is how you find out what users actually need, rather than what stakeholders assume they need. The two are often different.

The main methods at this stage are user interviews, contextual inquiry (watching people do the thing in their real environment), surveys for quantitative signal, analysis of existing data (analytics, support tickets, previous research), and competitive analysis to understand what alternatives exist.

UX research methods is a large topic. The short version is that good research at this stage is about asking open questions, observing real behaviour, and resisting the urge to confirm what you already think. Confirmation bias in research is not unusual. Guarding against it is a skill.

The output of research is raw data: interview notes, recordings, survey responses, analytics exports. That data is not yet useful until you have made sense of it.

3. Synthesis

Synthesis is the work of turning raw research data into insight. It is the stage that most newcomers to UX underestimate.

The main techniques are affinity mapping (grouping observations and quotes by theme to find patterns), journey mapping (charting the steps a user takes through an experience and where friction occurs), and personas (composite profiles that represent different user types based on research rather than assumption).

Synthesis usually involves collaborative sessions where the team works through the data together, often on a physical or digital whiteboard. Tools like Miro and FigJam are built for this. The reason you involve the team rather than doing it alone is that synthesis is interpretive, and having multiple people challenge each other's interpretations produces more reliable insight.

The output is a defined problem statement or set of "how might we" questions that the ideation stage will work from.

4. Ideation

Ideation is where solutions are generated. The key word is "generated" rather than "chosen" — the goal of ideation is quantity first, quality later.

Common formats are "how might we" question framing (turning a problem statement into a generative question), individual sketching followed by sharing, and design studios where the team sketches multiple solutions and discusses the ideas rather than the people who produced them.

Good ideation is deliberately uncritical. Evaluating ideas too early in the process kills the less obvious solutions before they have been considered. The evaluation comes after, when there are enough options to compare.

The output is a set of candidate directions, usually as rough sketches or concept notes, ready to be narrowed down and taken into prototyping.

5. Prototyping

A prototype is a representation of a design that can be tested without being built. The question at this stage is always: what is the minimum fidelity needed to test the thing we need to learn?

Lo-fi prototypes — paper sketches, rough wireframes, basic clickable flows in Figma — are fast to produce and fast to throw away. They are right for early-stage testing when the fundamental structure of the experience is still in question. They also communicate cheapness clearly, which encourages test participants to be honest rather than polite.

Hi-fi prototypes — detailed Figma files with real UI, realistic copy, interactive components — are right when the structure is settled and you need to test specific interactions, visual design decisions, or edge cases. They take longer to build and are harder to revise, so using them too early is expensive.

The most common prototyping mistake is jumping to hi-fi before the core flow has been validated. This is partly because hi-fi looks more impressive in stakeholder reviews, which creates the wrong incentive.

6. Usability testing

Usability testing means putting the prototype in front of real users and watching what happens. Not asking them if they like it. Watching what they do, where they get stuck, and what they say while they are doing the task.

The standard format is a moderated session: one facilitator, one participant, a set of tasks to complete, and a recording running. Five to eight sessions is usually enough to surface the main patterns. You are not looking for statistical significance — you are looking for friction, confusion, and failure points.

Heuristic evaluation is an alternative method when you cannot recruit participants quickly — a structured review of the design against established usability principles. It is faster and cheaper than testing but less reliable because it replaces real user behaviour with expert judgement.

The output of testing is a prioritised list of issues to address before the next iteration or before build begins.

7. Handoff

Handoff is the point where the design is transferred to engineering for build. A poor handoff is one of the most common sources of quality loss in product development.

A good handoff means the design files are organised and annotated in Figma: component states documented, spacing and sizing specified, interaction behaviour described, edge cases covered. It also means being available to answer questions during build rather than disappearing after the design is "done."

The distinction between UX and UI design becomes concrete at handoff. The UX layer — flows, information architecture, component logic — is what the engineering team builds from. The UI layer — visual polish, motion, brand details — is what makes it look right. Both need to be in the handoff package, but they are different things and they require different attention during build review.

Handoff is also where designers learn whether their decisions are actually buildable. Some things that look straightforward in Figma are expensive or technically complex to implement. Building a good relationship with engineering early in the process — not just at handoff — makes this less likely to become a problem.

8. Launch and iteration

Launch is not the end of the process. It is the beginning of the next research cycle.

After launch, analytics data shows what users are actually doing with the shipped product. Support tickets surface problems that testing did not catch. A/B tests (where they are appropriate) give signal on specific design decisions. This data feeds back into discovery for the next iteration.

In a product team, this loop runs continuously. There is no "finished" state — only the current version and the queue of improvements being worked on. Understanding this is important for anyone coming from a background where projects have a defined end.

The Double Diamond

The Double Diamond is a model developed by the Design Council that is worth knowing because it explains the underlying logic of the process clearly.

The idea is that good design involves two rounds of diverge-then-converge thinking. The first diamond is about the problem: you start by opening up your understanding of the situation (research, discovery), then converge on the right problem to solve (synthesis, problem definition). The second diamond is about the solution: you open up again with possible approaches (ideation, prototyping), then converge on the right solution to build (testing, iteration).

In practice, most teams compress this. The two diamonds run simultaneously rather than sequentially, loops happen within each stage, and commercial pressure means the converging usually happens faster than it should. Knowing the model is useful because it helps you diagnose where a team is cutting corners and what the likely consequences are.

Process in agile teams

Agile product development works in short cycles called sprints, typically two weeks. UX work has to fit inside those cycles, which means the full research-to-handoff arc gets compressed.

What this usually looks like in practice is "dual-track" agile: one track doing discovery and design work that stays one or two sprints ahead of engineering, and one track building from designs that have already been validated. Research happens continuously rather than in a dedicated phase. Synthesis and ideation are squeezed into shorter sessions. Prototyping is often just enough to test the critical interaction before build starts.

The thinking does not change. The timelines do. Doing UX research in agile development requires knowing what you can compress without losing the signal and what you cannot cut without guessing.

Tools at each stage

The tools UX designers use map fairly closely to the stages described above:

• Discovery and research: Google Docs or Notion for brief documentation, interview recording tools (Teams, Zoom, Lookback), survey platforms (Typeform, Google Forms)
• Synthesis: Miro or FigJam for affinity mapping and journey mapping, Dovetail or Notion for storing and tagging research notes
• Ideation: Paper and pen first, then Miro or FigJam for structured sessions
• Prototyping: Figma for both lo-fi and hi-fi work — it handles the full range from rough wireframes to interactive prototypes
• Testing: Maze or Lyssna for unmoderated testing, Lookback or Zoom for moderated sessions
• Handoff: Figma again, with organised layers, components, and annotations; Zeplin is still used in some teams

The tools matter less than the thinking. Designers who understand the process can use unfamiliar tools. Designers who know the tools but not the process are applying techniques without understanding why.

Learning the process in practice

Reading about the UX design process gives you a map. Working through it on a real project gives you the experience of using one.

The difference matters more than people expect. Interview techniques that read straightforwardly are hard to execute when a participant gives one-word answers. Synthesis that looks logical as a framework is genuinely difficult when you are staring at 40 interview quotes that seem to point in different directions. Presenting design decisions to a sceptical stakeholder requires a different skill set from making those decisions in the first place.

That gap between knowing and doing is why portfolio projects made from tutorial briefs rarely communicate the right things to hiring managers. They show you can use Figma. They do not show you can run a process.

On the Beginner UX Design and UX Career Track courses at UX Academy, you work through a real client brief end-to-end, from discovery through to a tested and presented final design. The instructors who run the process with you have done it professionally at companies including Adobe, Google, and Canva. If you are switching careers to UX design, that kind of grounded, supervised practice is what builds the confidence to run the process on your own.