The UX Design Process: 7 Steps, and Where Each One Goes Wrong

The UX design process has seven steps: define the problem and how you'll measure it, research your users, map the structure and key flows, wireframe and prototype, test with real people, finish the visual design and hand off to developers, then launch and keep learning. Expect to loop back. It's rarely a straight line.

Most guides to the UX design process stop at naming the stages. That's the easy part. What you actually need to know, especially if you're the one paying for the work, is what each step should hand you at the end and how to spot when it's quietly going off the rails. So that's what this guide covers, step by step, for websites and apps alike.

Step 1: Define the problem (and the number that tells you it's solved)

What you do. Write down, in a sentence or two, what's wrong and for whom. Then agree on one or two signals that would show it's fixed. Not "improve the experience". Something like "people who start a booking should finish it" or "new users should reach their first saved project without contacting support."

What you get. A short brief everyone signs off on. It names the users, the problem, the constraints (deadline and tech stack, for a start) and the measure of success.

What goes wrong. The brief describes a solution instead of a problem. "We need a new dashboard" is a solution. "Account managers can't tell which clients are at risk until it's too late" is a problem, and it might not need a dashboard at all.

The other failure is skipping this step because everyone "already knows" the goal. They usually know different goals. A 30-minute conversation here saves more rework than almost any other hour in a project.

Step 2: Research your users

What you do. Talk to the people who'll use the thing. Five or six interviews with the right people beat a survey of hundreds with the wrong questions. Look at analytics if you have them, read support tickets and app store reviews, and sit with your sales team for an afternoon. If there's an existing product, watch someone use it without helping.

What you get. A clear picture of what users are trying to get done, what they currently do instead, where they get stuck, and the words they use to describe all of it. Usually written up as a short findings document and a journey map.

What goes wrong. Plenty.

• Asking people what they want. They'll tell you features. Ask what they did last time they had this problem, and what annoyed them about it.
• Researching only your happiest customers. They've already learnt to work around your gaps. The people who signed up and left are more useful.
• Treating personas as the deliverable. A persona called "Marketing Maya, 34, loves coffee" helps nobody. What matters is the behaviour behind it.
• Doing it once. Research shouldn't stop at kickoff. Small, regular conversations through the project keep the team honest.

How much research is enough? Enough that you'd be surprised if the next interview told you something big and new. For a focused feature, that can be a week. For a new product in an unfamiliar market, it's more.

Step 3: Map the structure and key flows

This is information architecture, and it's the step clients most often want to skip because there's nothing pretty to look at yet. Don't let them. (If you're the client: don't skip it.)

What you do. Decide what content and features exist, how they're grouped, what they're called, and the paths people take through them. For a website, that's a sitemap and navigation labels. For an app, it's the main user flows: sign-up, the core task, settings, recovery when something fails.

What you get. A sitemap or screen inventory, plus flow diagrams for the journeys that matter most.

What goes wrong. Navigation gets organised around your org chart. Visitors don't care that "Solutions" and "Services" are owned by different teams; they just see two menu items that sound the same. The fix is to use your users' words, which you'll have from Step 2, and to test labels early with a quick card sort or tree test.

The second common miss is designing only the happy path. Say you run a booking app. What happens when the slot someone picked is taken by the time they pay? When their card fails? When they lose signal halfway through, or need to move the booking to next week? Those moments decide whether people trust you, and they need flows too.

Step 4: Wireframe and prototype

What you do. Sketch layouts in low fidelity: boxes and real-ish headings, with no colour. Then link the key screens into a clickable prototype you can put in front of people.

What you get. Something testable. That's the whole point of this step. Think of a wireframe as a cheap way to be wrong.

What goes wrong. The usual mistakes:

1. Lorem ipsum everywhere. Placeholder text hides the hardest problems. A product card looks fine until the real product names turn out to be four lines long. Use real or realistic copy from the start.
2. Jumping to high fidelity too soon. Once something looks finished, people stop questioning the structure and start commenting on button colours.
3. Prototyping every screen. You only need to prototype the flows you're unsure about. A standard password reset doesn't need a fresh idea.
4. Designing for desktop and shrinking it later. For most consumer products, people will meet you on a phone first. Wireframe the small screen early, while the layout is still easy to change.

Step 5: Test with real people

If your UX design process cuts one step to save time, it's usually this one. It's also the step that pays back fastest.

What you do. Give five or so people from your target audience a realistic task ("Book a haircut for Saturday morning") and watch them try it on the prototype. Don't help. Don't explain. Note where they hesitate or give up. Nielsen Norman Group has argued for years that small rounds of around five users catch most usability problems, and that several small rounds beat one big one.

What you get. A ranked list of problems, from "nobody could find the button" to "two people paused at this label." Then you fix the worst ones and test again.

What goes wrong.

• Testing with colleagues. They know too much.
• Asking "Do you like it?" Liking tells you nothing. Watching tells you everything.
• Defending the design in the room. If a participant struggles, write it down. That's the finding.
• Testing too late, when the budget for changes is gone.

Accessibility belongs here too, not as a final checklist. Check colour contrast, text size, keyboard use and screen reader behaviour while changes are still cheap. WCAG 2.2, a W3C Recommendation since October 2023, is the standard most teams work to. We go into the details in our guide to accessibility in UX design.

Step 6: Visual design and developer handoff

What you do. Apply type, colour, spacing, imagery and motion to the tested structure. Build reusable components rather than one-off screens. Then prepare the files developers need.

What you get. Final designs, a component library or style guide, and specs for every state: default, hover, focus, loading, empty, error, disabled. If you're unclear where this step ends and earlier ones begin, our piece on UI vs UX design draws the line.

What goes wrong. Handoff is where good design quietly dies. Imagine a checkout where the designer drew the success screen beautifully but never drew the "card declined" message. The developer, under deadline, writes "Error 402" in red. Nobody meant for that to happen. Nobody designed it either.

The fix is boring and effective: list every state for every component, keep designers involved through the build, and review the working product, not just the mockups. If you're shipping a lot of screens, a small design system pays for itself quickly. And this is why we prefer having designers and engineers on one team for web development and mobile app development: fewer things get lost in translation.

Step 7: Launch, measure, and keep going

What you do. Ship it. Then go back to the measure you set in Step 1 and check it. Look at where people drop off, watch session recordings, read support tickets, and talk to a few new users again.

What you get. Evidence about what's working, and a prioritised list of what to fix next.

What goes wrong. Teams treat launch as the finish line, move on to the next project, and never check whether the original problem got solved. Six months later someone commissions a redesign without knowing what went wrong with the last one. A periodic UX audit is a simple way to stop that drift.

---

How long does the UX design process take?

It depends far more on scope and decision speed than on the steps themselves. A focused change to one flow can move through all seven steps quickly. A new product with unknowns in the market takes much longer, mostly in research and testing. The biggest variable is usually how fast feedback comes back from the client side, not how fast designers work.

Can you skip steps in the UX design process?

You can shrink every step. Skipping one outright is where projects get into trouble. A small project might do two days of research instead of two weeks, or test a paper sketch instead of a polished prototype. That's fine. What isn't fine is going straight from a brief to final visuals, because you end up testing your assumptions in production, with real customers, which is the most expensive place to find out you were wrong.

Is the UX process different for websites and apps?

The steps are the same. The weight shifts. On a marketing website, structure and content (Step 3) carry most of the load: can people find what they came for and understand what you offer? In an app, flows, states and repeat use matter more, so Steps 4 to 6 get deeper. Apps also need more design for things going wrong, like failed syncs, permissions and offline use.

---

If you'd like a team to run this process with you, or just a second opinion on where yours is getting stuck, have a look at how we approach UI/UX design. When you're ready to talk specifics, you can tell us about your project.