What is UX design? The UX design process step by step

In short

UX design starts with questions, before anything goes on the screen. Who will use the product, what do they want to achieve, where do they get stuck? Drawing only starts once these questions are answered.

I explain the term itself in the glossary entry UX (user experience). I describe the difference between UI and UX in the UI and UX guide. This page focuses on how the work gets done, that is, on the process.

The process has a single rule: information from users has the last word. This is called user-centred design. The international standard for this approach is ISO 9241-210.

The UX design process: seven steps

I split the process into seven steps. Each has a tangible output. A step without an output stays a meeting.

Process diagram

1. 1Research

   1. Research

   Output

   Note on the context of use: who uses it, with what goal, on which device. Interview notes and profiles of the user groups.

   Duration

   Depends on the scope and on how easily you can reach users. In a new product it can be one of the longest steps.

   Tools

   Interview guide, video call with recording, analytics dashboard, support requests.

   Match in the models

   ISO 9241-210: Understand and specify the context of use. Double Diamond: Discover.

2. 2Define

   2. Define

   Output

   Problem statement in one sentence, list of user requirements and their priority.

   Duration

   A short, dense step. Once the research notes are in, it is done in a few joint sessions.

   Tools

   Digital whiteboard (to cluster the notes), shared document.

   Match in the models

   ISO 9241-210: Specify the user requirements. Double Diamond: Define.

3. 3Ideate

   3. Ideate

   Output

   Flow sketches, rough scribbles and a few solution directions chosen from them.

   Duration

   Deliberately short. First many options appear, then most of them drop out.

   Tools

   Pen and paper, whiteboard, flowchart tool.

   Match in the models

   ISO 9241-210: Produce design solutions. Double Diamond: Develop.

4. 4Proto­type

   4. Prototype

   Output

   Wireframe, usage scenarios and clickable prototype. It moves from the rough to the realistic version.

   Duration

   Depends on the prototype’s level of detail. A rough draft is quick; a realistic prototype takes longer.

   Tools

   A design tool such as Figma, a paper prototype or code directly.

   Match in the models

   ISO 9241-210: Produce design solutions. Double Diamond: Develop.

5. 5Test

   5. Test

   Output

   Usability test report: who got stuck where, how serious each problem is, what comes next.

   Duration

   A single round is short. Testing often with a few people teaches more than a rare big test.

   Tools

   Prototype link, video call, screen recording, note template.

   Match in the models

   ISO 9241-210: Evaluate the design against the requirements. Double Diamond: Deliver (testing at small scale).

6. 6Ship

   6. Ship

   Output

   Development-ready design file, components and, in the end, the live interface.

   Duration

   Depends on the team and scope. Shipping in small pieces speeds up learning.

   Tools

   Design file, design system, code repository.

   Match in the models

   ISO 9241-210: Produce design solutions (implemented interface). Double Diamond: Deliver.

7. 7Measure

   7. Measure

   Output

   Metrics dashboard, field notes and user survey results. They provide the research input for the next round.

   Duration

   Never ends. It runs as long as the product is live.

   Tools

   Web analytics, survey form, support requests, session recording tool.

   Match in the models

   ISO 9241-210: Evaluate (long-term monitoring). Double Diamond: Discover again.

Loop: if the test result isn’t good enough, go back to Define or Prototype. Measure also provides the input for the next round’s research.

Press a step: its output, how long it takes and the tools it is done with appear below. The duration is deliberately given without numbers, because it differs in every project.

Read the order in the diagram as a suggestion. For a small change, research can mean reading a few support requests. In a new product it is often one of the longest steps.

The two models behind the process

I didn’t invent the seven steps. I started from two widely used models and adapted them to day-to-day work. One is ISO 9241-210, the other the Design Council’s Double Diamond.

ISO 9241-210: human-centred design

ISO 9241-210 is the standard for human-centred design of interactive systems. In this guide I rely on the second edition from 2019. The standard doesn’t assume any particular design process and can be built into approaches as different as the waterfall model.

The standard names four activities:

1. Understand and specify the context of use.
2. Specify the user requirements.
3. Produce design solutions that meet these requirements.
4. Evaluate the design against the requirements.

Table 1 of the standard also lists example outputs of each activity. The context produces profiles of user groups and personas. Design produces low- and high-fidelity prototypes, evaluation a usability test report.

The standard also has six principles. I rely on two the most: users are involved throughout design, and the process is iterative. The standard counts an incomplete or inappropriate understanding of user needs among the major sources of systems failure.

Double Diamond: two diamonds, four phases

The Double Diamond is a model the UK Design Council introduced in 2004. It consists of two diamonds. In each diamond the topic is first opened up, then narrowed down.

The first diamond is about the problem. The Discover phase tries to understand the problem rather than assume it. The Define phase reframes the problem with the insight gathered.

The second diamond is about the solution. In the Develop phase different answers are produced. In the Deliver phase solutions are tested at small scale, and what doesn’t work is dropped.

The Design Council says explicitly that the model is not a linear process. One of the four principles in its framework for innovation is: iterate, iterate, iterate.

How the seven steps fit the two models

Step	ISO 9241-210	Double Diamond
1. Research	Understand and specify the context of use	Discover
2. Define	Specify the user requirements	Define
3. Ideate	Produce design solutions	Develop
4. Prototype	Produce design solutions	Develop
5. Test	Evaluate the design against the requirements	Deliver (testing at small scale)
6. Ship	Produce design solutions (implemented interface)	Deliver
7. Measure	Evaluate (long-term monitoring)	Discover again

My difference: neither model draws the time after launch as a step of its own. I keep Ship and Measure separate. In small teams, this is exactly the part that gets skipped most often.

The steps in detail

1. Research

The aim is to understand the context of use. ISO 9241-210 describes the context as a combination of users, goals, tasks, resources and environment. So what matters isn’t only the person in front of the screen but also the circumstances in which they look at it.

Imagine you are redesigning an online store’s returns flow. First you talk to a few customers who have started a return and read the most common questions to support. Often the person can fill in the form. Where they really get stuck: they can’t find where the return starts.

2. Define

You cluster the research notes and condense them into a single problem statement. “The customer can’t find where the return starts on the Orders page” is a good sentence. “Returns are bad” says nothing at all.

Then you write down the requirements. If wishes contradict each other, you decide at this step which one takes priority.

3. Ideate

Don’t commit to a solution straight away at this step. I first draw many paths with rough sketches and then cross most of them out. That is exactly the opening part of the second diamond in the Double Diamond.

In the returns example, two paths may stand out: a “Return” button on the order card or a link in the shipping notification. You don’t know yet which is right. The test will tell you.

4. Prototype

You turn the chosen direction into something testable. ISO 9241-210 takes a broad view of the prototype: it can be a simple sketch or an almost fully working system.

I usually start with a wireframe of grey boxes. Once the flow works, I move on to a clickable prototype. If the prototype is more realistic than needed, the test participant looks at the colours more than at the flow.

5. Test

You put the prototype in front of real users and give them a task: “Return the shoes you bought last week.” Then you stay quiet and watch.

This observation shows how usable the flow is. Where the person hesitates says more than what they say.

People often ask how many participants are needed. Jakob Nielsen writes in a 2000 article that a first test with five users finds 85 percent of the usability problems. That is why he recommends three tests with five people each instead of one test with fifteen.

The test produces a list of findings. How I word findings and rank them by severity is described in the UX audit guide.

6. Ship

A design is a hypothesis until users touch it. At this step the design file becomes development-ready, and the interface goes live.

Details lost between design and development are what I see most often at this step. Empty states and error messages exist in the design and are forgotten in the code. When design and code sit with the same person, this loss gets smaller.

7. Measure

The live product tells you things the prototype can’t. Are more people starting returns, and does the question “Where is the return?” reach support less often?

ISO 9241-210 also counts this part as evaluation and lists the results of long-term monitoring as an output. The Design Council writes too that no idea is ever finished. The question from measurement is the research of the next round.

Example: seven steps in a banking app

A made-up example: in a bank’s mobile app, autopay for bills is hardly used. The team wants to redesign the autopay screen. This is how the process runs.

1. Research. The team talks to a few customers who pay their bill by hand every month. Most don’t know the feature exists. Some of those who know it fear that a wrong amount will be charged.

2. Define. The problem statement reads: customers don’t see in advance when and how much autopay will charge. The requirement follows: a notification before the charge and a way to cancel.

3. Ideate. The team sketches a suggestion card after paying a bill, a separate page for autopay and a notification before the charge. The team decides to test the suggestion card and the notification together.

4. Prototype. First the flow is drawn on paper. Then the suggestion card and the notification screen are made clickable.

5. Test. In the round with five people, two can’t read the date in the notification. The team makes the date bigger, puts it next to the amount and runs a new round.

6. Ship. The change is first rolled out to a small share of users. Error messages and the cancel screen are already finished in this version.

7. Measure. The team looks at the number of new autopay set-ups and the cancellation rate. If cancellations are higher than expected, it goes back to research and asks customers why.

In this example no step takes weeks. The steps are small, but none is skipped. My projects often run at this scale too.

To name the problems found in a test, Nielsen’s 10 heuristics give a shared language. The date problem in the example concerns the heuristic visibility of system status.

The process isn’t a straight line

Written as a list, the seven steps look as if you walk through them in order. In reality the process is a loop. ISO 9241-210 says that the most appropriate design for an interactive system typically can’t be achieved without iteration.

The standard also explains why. Many user needs only emerge during development. And users describe their needs better when a possible solution is in front of them. That is why it isn’t possible to write down every detail completely and correctly on day one.

In practice this means: if the test goes badly, go back to the prototype. If the problem was defined wrongly, back to Define. The Design Council gives a similar warning: a problem that turns up along the way sometimes sends the team all the way back to the start.

How the process works in a small team

The seven steps can look as if they need a big research team. But a small team can go through all of them too. ISO 9241-210 says that how often users are involved depends on the nature of the project.

In a one-person startup, research can be a few short conversations with customers. For the test, a prototype link and a video call are enough. Don’t skip steps; keep each one small.

My Design & Ship Sprint is built for exactly this small loop. Design and code sit with the same person for two weeks, and the result goes straight into your repository.

Common mistakes

Skipping research and drawing right away. The screen is carefully drawn but answers the wrong question. The standard’s first principle is that design is based on an explicit understanding of users, tasks and environments.

Defining the problem together with the solution. “We need a new menu” isn’t a problem but a solution. The problem statement shouldn’t name any part of the interface.

Falling in love with an idea early. The first sketch is usually the most familiar, but familiar doesn’t mean right. Don’t choose without putting several paths side by side.

Putting the test off until after launch. Fixing a mistake live costs more than in the prototype. Small, early tests lower that cost.

Testing within your own team. Those who build the product know the flow by heart. Test with someone who has never seen the product.

Stopping after launch. If you move on to the next task without measuring, you never find out whether the change worked.

Leaving accessibility to the end. If contrast and keyboard use aren’t considered during design, retrofitting them is hard. The details are in the WCAG guide.

My note

What I see most often when working with teams is starting in the middle of the process. Someone comes with a screen idea, and the team goes straight to the prototype. Research and definition come afterwards, and then only to defend the idea.

That is why I start every piece of work with a single question: what does the person who opens this screen want to do at this moment? If the answer is unclear, I don’t start drawing.

My second observation is about measuring. Teams treat the launch as the finish line. Yet the real learning only starts once the product has been live for a few weeks.