UX Design Methodology: The Five Stages, Explained

A UX design methodology is a structured, repeatable approach to solving design problems with evidence rather than opinion. It sets out which stages a team goes through, which research methods it uses at each stage, and how decisions get validated before anyone builds anything.

There are several named methodologies in common use, and they overlap heavily. Underneath them all sits the same five-stage sequence. This page covers both: the frameworks and when each one fits, then the five stages in detail, then how to choose research methods without running every study in the textbook.

One distinction first, because it causes confusion. Usability asks whether a person can complete a task without friction. UX contains usability and adds everything the person feels before, during and after the interaction. A site can be perfectly usable and still be unpleasant to use.

The named methodologies, and when each fits

These are frameworks for organizing the same underlying work. Teams argue about which one they follow, and in practice the difference shows up in how fast they loop and how much they document.

Design Thinking

Five phases: empathize, define, ideate, prototype, test. Popularized by IDEO and the Stanford d.school, it is the most widely taught framework and the most flexible. Its strength is the explicit separation of understanding the problem from generating solutions, which is where most teams cheat.

Best for: a new product, an unclear problem, or a team that needs a shared vocabulary. Weakest when the problem is already well understood, where the ceremony adds time without adding information.

User-Centered Design

The formal version, codified in ISO 9241-210, built on four iterative activities: understand the context of use, specify the requirements, produce design solutions, and evaluate against the requirements. It is the framework regulated industries and large enterprises use because it produces an audit trail.

Best for: medical devices, finance, government, accessibility-critical products, and anywhere a design decision may have to be justified later. Heavier than a startup needs.

The Double Diamond

The British Design Council model: two diamonds, each widening then narrowing. The first diamond discovers and defines the problem, the second develops and delivers the solution. Its main contribution is making explicit that you diverge twice, not once, and that the problem definition in the middle is a deliverable in its own right.

Best for: communicating the process to stakeholders who think design starts at the mockup stage. It is the clearest diagram in the field for that purpose.

Lean UX

Built around hypotheses and the smallest experiment that can test them. Instead of a research phase followed by a design phase, you write an assumption, build the minimum artifact that tests it, and measure. Documentation is deliberately thin.

Best for: early-stage products where speed of learning matters more than completeness, and where you can actually measure the outcome. It fails when the team uses "lean" as a reason to skip research entirely.

Agile UX

Not a separate philosophy so much as an operating model: UX work runs alongside engineering sprints rather than ahead of them, usually one or two sprints in front. Research is continuous and small, and the design backlog is groomed like any other.

Best for: an existing product with a shipping engineering team. The recurring problem is that design gets compressed into the sprint and research is the first thing cut, so it takes deliberate protection.

Waterfall, and why it still appears

Each phase completes and is signed off before the next begins. It is out of fashion for good reasons: you find out late, and changing anything is expensive. It survives in fixed-price agency contracts and in procurement processes that require a defined scope up front. If you are locked into it, front-load the research and build in at least one testing gate.

How to choose

• New problem, no existing product: Design Thinking or the Double Diamond.
• Existing product, shipping team: Agile UX.
• Regulated or accessibility-critical: User-Centered Design, ISO 9241-210.
• Early stage, need to learn fast, can measure: Lean UX.
• Fixed-price contract: waterfall with a testing gate written into the scope.

Most working teams end up with a hybrid, and that is fine. The purpose of naming your methodology is to make the team agree on what happens before styling starts.

Why a structured approach pays

The argument for methodology is economic rather than aesthetic. The cost of fixing a design problem rises steeply with how late you find it. A confusing flow spotted in a prototype test costs an afternoon of rework. The same flow spotted after launch costs an engineering cycle, a release, and whatever the confusion cost you in the meantime.

Research also prevents the most expensive mistake, which is building something nobody wanted. That failure is invisible on a design review and obvious in the analytics six months later. Every hour of user interview upfront is buying you the option not to build a feature.

The third benefit is organizational. A documented process is what lets a designer say no to a stakeholder request without it becoming a personality conflict. The evidence carries the argument.

The five stages

A UX project is iterative, not linear. The stages below run in order the first time and then loop, with each cycle narrowing what is still uncertain.

1. Planning and scoping

Before thinking about the user, get the people paying for the work aligned. This stage exists to prevent a redesign being canceled in month three because two executives wanted different things.

• Define the objective: what are we trying to change, and what is the single measure of success?
• Set the scope and methods: which research and testing techniques will be used, and which will not.
• Plan resources: budget, schedule, and above all who you will recruit for research, which is usually the longest lead item.
• Gather what exists: previous studies, support tickets, analytics, sales objections. Most companies are sitting on more user evidence than they think.
• Explain the process: stakeholders who do not know what a wireframe is for will ask for color on it.

2. Exploration and research

The core of UX work. The aim is to understand the people you are designing for well enough to predict where they will struggle. You want both numbers and reasons, because neither alone is enough.

Quantitative methods answer how much and how many:

• Analytics review: most-viewed pages, drop-off points, conversion by step, device mix.
• Behavioral tools: heatmaps, click maps and session recordings from Hotjar, Microsoft Clarity or similar, showing where people scroll, click and hesitate.
• Surveys: cheap validation at scale once you know which question matters.
• Tree testing: testing a navigation hierarchy in text form to check whether people can find things before you design the menu.

Qualitative methods answer why and how:

• User interviews: the highest-value method in the field. One to one, open questions, five to eight people per user group.
• Contextual inquiry: watching people work in their own environment, which surfaces the workarounds they never mention in an interview.
• Focus groups: useful for reactions to a concept, unreliable for predicting behavior.
• Competitive UX review: what conventions do users already expect, and where is there an opening?
• Heuristic evaluation: expert review against recognized criteria such as Nielsen's ten heuristics or the Bastien and Scapin framework. Fast, cheap, and no substitute for real users.

Cross the two. Analytics tell you where people abandon the checkout. Only an interview tells you it was because the shipping cost appeared at the last step.

3. Ideation and definition

You now have a pile of findings. This stage turns them into a defined problem and then into candidate solutions.

• Empathy map: a synthesis of what a user thinks, feels, says, does, sees and hears. A fast way to get a team to a shared understanding.
• Personas: archetypes built from real research data, used to keep decisions specific. Designing for "everyone" reliably produces something that suits nobody.
• User journey map: every stage and touchpoint on the way to a goal, which is how you locate friction across the whole experience rather than one screen.
• Information architecture: organizing and ranking content so navigation is logical. Card sorting, where users group labels themselves, produces a structure that matches their mental model rather than your org chart.
• Co-design workshops: sessions with designers, engineers, marketing and ideally real users, to generate and rank ideas collectively.

4. Design and prototyping

Make it tangible, at increasing levels of fidelity, so it can be tested cheaply.

• Wireframes: the skeleton. Grayscale, structural, deliberately unstyled so the conversation stays on hierarchy and flow.
• Mockups: high-fidelity static screens with real color, type and imagery. Realistic, but still an image.
• Prototypes: an interactive simulation. Screens linked, navigation working, states visible. Close enough to the real thing to test properly, and built in Figma or ProtoPie rather than in code.

A prototype is not the product. Its job is to test a hypothesis about the experience, which is exactly why it can be changed dozens of times in the time development would take to change it once.

5. Evaluation and iteration

Put it in front of users and find out.

• Usability testing: the most reliable method. Watch a participant attempt specific tasks and think aloud. Five per persona surfaces the large majority of serious problems, which is why it is cheap relative to its value.
• A/B testing: quantitative comparison of two versions against one objective, once you have enough traffic for the result to mean anything.
• Satisfaction instruments: standardized questionnaires such as the System Usability Scale give you a comparable score over time rather than a one-off impression.

What you learn here feeds the next round of ideation. The loop closes and runs again, and it keeps running after launch.

Choosing the right research methods

Teams either run no research or try to run everything. The useful way to choose is to place methods on two axes.

• Attitudinal or behavioral: are you asking what people say, or observing what they do? Surveys and interviews are attitudinal. Analytics, session recordings and usability tests are behavioral. What people say and what they do diverge routinely, so never plan a product on attitudinal data alone.
• Qualitative or quantitative: are you learning why, or how many? Qualitative gives you the mechanism, quantitative gives you the size. You need the mechanism first, or you will optimize the wrong number.

A workable minimum for most projects is one method from each quadrant: an analytics review, a set of interviews, a survey to size what the interviews surfaced, and a usability test on the prototype. That is four studies, not fourteen, and it covers the questions that actually change a design decision.

Then match the method to the stage. Discovery wants interviews and contextual inquiry. Definition wants card sorting and tree testing. Evaluation wants usability testing and A/B tests. Running a usability test during discovery, on a product that does not exist yet, is a common and expensive category error.

Good practice worth holding to

• Make the path obvious: the user should never have to ask where they are or what to do next. Every step clear, every state accounted for, including empty and error states.
• Treat load time as a design problem: a slow page is a usability failure and a ranking factor. Compress images, defer what is not needed, and measure on a real mobile connection rather than office wifi.
• Design mobile first: over half of web traffic is mobile. Starting with the smallest screen forces you to decide what is essential.
• Use color deliberately: to rank information and to direct attention to the primary action. Then check contrast ratios, because a palette that fails accessibility is not a design choice.
• Structure the content: clear headings, short paragraphs, lists. Nobody reads a wall of text on a screen, and scannability is a design responsibility rather than a writing one.
• Test with five people rather than none: a rough guerrilla session with three to five users beats a perfectly planned study that never happens.

Running this without a full in-house team

Maintaining a UX practice takes specific skills and steady discipline, which is expensive to hold in house at small scale. Our design subscription gives you access to senior UX and UI designers on a fixed monthly fee, with plans from 949.90 euros excluding VAT a month for Prestige, 1,399.90 euros for Elite, and 2,099.90 euros for Commando with no commitment, or 759.90 euros a month on a twelve month term.

That covers personas, wireframes, high-fidelity mockups and prototype iteration, and the higher plans run several requests in parallel, which is what an iterative cycle needs. For the sequence in more detail, see our walkthrough of the UX/UI design process, and for evaluating what you already have, the UX audit method.

Where to start

Pick one framework and write it down so the team stops arguing about sequence. Book five user interviews this month. Pull your analytics for the flow that matters most and find the drop-off. Then wireframe the fix and test it on five people before anyone opens a color picker. That is the whole methodology, and it works at any scale.

FAQ