A UX design process is the sequence of steps a team uses to understand users, decide what to build, and check that it works before and after it ships. Every team draws the diagram slightly differently, but the good ones share the same logic: learn first, commit later, and test with real people at every stage where a wrong guess would be expensive.
This guide walks through the stages we use, explains what each should produce, and flags where founders and small teams most often cut corners. It is written for people commissioning design as much as for people doing it.
The UX design process at a glance
There is no single official version of the UX design process, but most frameworks trace back to the same idea. Nielsen Norman Group's Design Thinking 101 describes six phases grouped into three larger steps: understand (empathize, define), explore (ideate, prototype) and materialize (test, implement). We use a version of that model, with plain names.
| Stage | Main question | Key outputs |
|---|---|---|
| 1. Research | Who are the users and what are they trying to do? | Interview notes, analytics review, journey map, assumptions list |
| 2. Define | What exact problem are we solving, for whom? | Problem statement, success metrics, prioritized user needs |
| 3. Ideate | What are the possible ways to solve it? | Sketches, flow options, information architecture drafts |
| 4. Prototype | What could the chosen solution look like? | Wireframes, clickable prototypes |
| 5. Test | Can real users complete the task? | Usability findings, fixes, a revised prototype |
| 6. Build and measure | Does it work in production? | Final UI, component specs, analytics, post-launch findings |
Stage 1: Research
Research is about learning how people behave today, before you decide what to change. The UK Government Digital Service calls this the discovery phase and gives advice any team can use: understand your users and what they are trying to achieve, understand the constraints, and reframe a proposed solution as a problem to be solved. It says there is no set time period, but around 4 to 8 weeks is typical, and it is clear that you should not start building your service in discovery.
A startup rarely needs two months. It does need a handful of real conversations and a look at whatever data exists. Useful methods at this stage include:
- User interviews with people who have the problem, not just people who like the idea.
- Observation of how they solve the problem today, including spreadsheets and workarounds.
- Analytics and support tickets if a product already exists.
- A competitor walkthrough to see what users will compare you with.
- An assumptions list of everything the team believes but has not checked.
Stage 2: Define the problem
Definition turns research into a decision. The output is a short problem statement that names the user, their need and the obstacle, plus the measures that will tell you whether you solved it. "Make onboarding better" is not a problem statement. "New account owners cannot invite their team without contacting support, so most accounts stay single-user" is.
This is also where scope gets set. A clear problem statement is the best defense against feature creep, because every proposed feature can be checked against it. If the product is new, this is the right moment to decide whether you need a throwaway prototype or a real first release; our comparison of MVP vs prototype covers that choice.
Stage 3: Ideate and structure
Ideation is where a team generates several ways to solve the defined problem before picking one. The mistake here is falling in love with the first idea. Cheap sketches of three different flows take an afternoon and often reveal that the obvious approach has a hidden cost.
- Sketch several flows for the core task, on paper or a whiteboard.
- Draft the information architecture: what the main sections are called and where things live.
- Check each option against constraints from research, such as technical limits, legal requirements and budget.
- Pick one or two to prototype, and write down why the others were dropped.
Stage 4: Prototype
A prototype is a model of the solution that is good enough to test and cheap enough to throw away. Start low fidelity: grey boxes and real words, not colors and icons. Visual polish at this stage makes people comment on the styling instead of the flow, and makes the team reluctant to change it.
| Fidelity | What it looks like | Best for testing |
|---|---|---|
| Paper or sketch | Hand-drawn screens | Whether the overall flow makes sense |
| Low-fidelity wireframe | Grey layouts with real labels | Navigation, structure and wording |
| Clickable prototype | Linked screens in a design tool | Task completion and where people hesitate |
| High-fidelity prototype | Close to final UI with real content | Visual clarity, trust and fine interaction details |
This is also where UI begins to matter. Once structure holds up, the interface layer turns wireframes into screens people can actually use; our explainer on UI vs UX covers where that handover sits.
Stage 5: Test with real users
Usability testing means watching representative users try to complete real tasks with your prototype, without helping them. You do not need a large sample. In his widely cited article Why You Only Need to Test with 5 Users, Jakob Nielsen reports that the first study with five participants finds about 85% of the usability problems, and argues that a budget for 15 users is better spent on three studies of five, fixing problems between each round.
- Write three to five tasks based on the problem statement, not a tour of features.
- Recruit people who match your users, not colleagues or friends.
- Ask them to think aloud, and resist explaining the interface.
- Note where they hesitate, backtrack or give up, then fix those spots first.
- Retest the fixes; a change can introduce a new problem.
Stage 6: Build, measure and iterate
The UX design process does not end at handover. Designers and engineers should work together through the build, because real data, edge cases and performance limits will force decisions no prototype anticipated. Specs should cover every state (loading, empty, error, success), not just the ideal screen.
Accessibility needs to be designed in from the start rather than checked at the end. The W3C's WCAG 2.2 sets testable criteria such as a minimum contrast ratio of 4.5:1 for normal text and a minimum size for pointer targets. Fixing those in a component library once is far cheaper than fixing them screen by screen after launch.
After release, measure the success metrics you set in the define stage: task completion, drop-off, time to value, support requests. When a number slips, that is the trigger to go back to research, and the loop starts again. If you are planning the overall schedule, our guide to how long it takes to build an app shows where design fits into delivery.
Where teams cut the wrong corners
- Skipping research because the founder "already knows the users." Sometimes true, often not.
- Jumping to high fidelity before the flow is tested, which makes change expensive.
- Testing with colleagues instead of real users, which hides every problem insiders have learned to work around.
- Treating handover as the end so engineers make undocumented design decisions under deadline.
- Never measuring after launch, so nobody knows whether the design worked.
The right-sized UX design process for a small team is lighter, not different. Fewer interviews, smaller tests and shorter cycles still follow the same order.
Running the process with us
Our UI/UX and product design practice runs this process at startup speed: short discovery, a written problem statement, tested prototypes and a finished interface with a component library engineers can build from. Because design and engineering sit in the same team, the build stage does not turn into a guessing game, and you see progress in weekly demos.
If you have a product idea that needs shaping, or a live product where users keep getting stuck, tell us what you are building. We reply within one business day.
Frequently asked questions
What are the 7 pillars of UX design?
The seven pillars usually refer to Peter Morville's user experience honeycomb, which says a good experience is useful, usable, desirable, findable, accessible, credible and valuable. It is a checklist of qualities rather than a process. Each stage of the UX design process should move a product toward those qualities.
Is UX a difficult job?
It can be demanding. UX designers work with ambiguity, balance user needs against business and technical limits, and have to defend decisions with evidence rather than taste. The craft skills can be learned; judgment about what to research, what to cut and when to stop comes from real projects.
Is UX getting replaced by AI?
In our view, no, though AI tools are changing parts of the work. They can speed up tasks such as summarizing research notes or drafting layout options. They cannot talk to your users, decide which problem matters most to the business or take responsibility for a design decision, and those are the core of the job.
Can I learn UI/UX in 3 months?
You can learn the fundamentals and the main tools in three months of focused study. Becoming good at it takes much longer, because the hard parts are research, problem framing and learning from real users. A portfolio of real projects that shows your process matters more than the length of any course.
How long does the UX design process take?
It depends on the size of the problem. The UK government's service manual says around 4 to 8 weeks is typical for a discovery phase on a public service, while a startup feature might go from research to tested prototype in a few weeks. The better question is how many test-and-fix rounds you can afford before building.
