The UX Process at a Glance: From Problem to Solution

Every Monday, an adult education center gets dozens of phone calls. People want to know whether there are still spots in the Spanish class, why the online registration isn’t working, or where the class actually takes place. Management has a clear idea: “We need a new website. More modern, with an app.” The budget is approved quickly, an agency is found just as fast.

At this point, nobody knows whether the new website will actually reduce the calls. Because so far, nobody has asked why people are calling in the first place. Maybe registration is too complicated. Maybe information about the venue is missing. Maybe the callers are mostly older people who simply prefer talking on the phone. Each of these answers leads to a completely different solution.

This is exactly where the UX process comes in. It isn’t a rigid method, it’s more like a map: it shows you where you are in a project, which questions matter at that point and which shortcuts get risky. This article walks you through the map step by step, no prior knowledge needed. The adult education center serves as a running example throughout.

What “UX process” actually means

User experience (UX for short) describes the entire experience people have with a product or service: whether they reach their goal, how much effort it takes and how they feel along the way. A UX process is the sequence of steps a team uses to deliberately improve that experience. For more on the term itself, read What Is User Experience?.

One thing up front: there is no single UX process. There are several well-known models, such as the Double Diamond, Design Thinking or Lean UX. They differ in terminology and focus, but almost all of them follow the same core idea. Once you understand that idea, you’ll find your way around any of the models.

The core idea fits in one sentence: first find the right problem, then the right solution. Sounds obvious. In practice, though, the first part gets skipped so often that it’s worth taking seriously.

The core idea: opening up and narrowing down

The best-known picture of the UX process is the Double Diamond. It comes from the Design Council, an independent UK organization that promotes design, and according to the Design Council it was introduced in 2004. The model shows two diamonds side by side. The first one stands for the problem, the second for the solution.

Each diamond first opens up and then narrows down again. When it opens, you think broadly: you collect impressions, questions and ideas without committing to anything. This is called divergent thinking. When it narrows, you sort, select and make decisions. This is called convergent thinking.

An everyday comparison: when you’re looking for an apartment, you first browse lots of listings, including some that aren’t a perfect fit (opening up). Then you decide what really matters to you: location, size, rent (narrowing down). After that, you view several apartments (opening up) and finally sign a lease (narrowing down). If you take the very first apartment you see, you might get lucky. Usually, you regret it later.

The two diamonds give you four phases, which the Design Council names as follows:

1. Discover: understand what the problem really is instead of assuming it.
2. Define: organize what you’ve learned and reframe the challenge clearly.
3. Develop: come up with different possible solutions.
4. Deliver: test solutions at a small scale, drop what doesn’t work and improve what looks promising.

These four phases are the map you’ll get to know in the rest of this article. It’s extended by a fifth step that many models only touch on, but that matters a lot for beginners: what happens after launch.

The phases in detail

1. Understand: what’s really going on?

The first phase is about getting to know the people involved and their situation. The key question isn’t “What should we build?” but “What’s happening here, and why?” There’s a whole range of methods for this, grouped under the term user research: research with and about the people who use a product.

Typical methods in this phase include:

• Conversations with the people affected, often as semi-structured interviews with prepared, open-ended questions.
• Observation in the real environment, for example listening in at the registration phone line or sitting next to someone trying to sign up online.
• Existing data: support requests, website analytics, complaints.

In the adult education example, the team spends two mornings listening in on the registration line and notes what each call is about. They also talk to eight people who booked a class in recent months and look at where people most often drop off on the website. The result is surprising: roughly half of the calls aren’t about registration at all, but about a single question: “Is this class right for me?” The class descriptions barely explain what prior knowledge is needed.

What you have at the end: a collection of observations, quotes and patterns. No solution yet, and that’s exactly how it should be.

2. Define: which problem are we solving?

After the first phase, you usually have more material than you can process. Now the first diamond narrows: you sort your findings, spot patterns and decide which problem you want to tackle.

Tools that make findings tangible help here. A persona is a fictional profile of a typical user group, based on real data. A journey map shows the path people take step by step, including the points where things get stuck. Neither is an end in itself. They’re a way to make sure the whole team has the same picture in mind.

This phase ends with a clearly written problem statement. A good problem statement describes who wants to achieve what and where they fail. It deliberately doesn’t contain a solution yet.

Before: “We need a new website with an app.”

After: “People looking for a class can’t tell online whether a class matches their level. So they call, or they don’t sign up at all.”

That’s a big difference. The first version already dictates the solution. The second leaves room for several solutions, and it makes it measurable whether a solution works: namely, when fewer people call with exactly this question.

What you have at the end: a shared, written problem statement and a goal you can use to measure success later.

3. Develop ideas: which solutions are possible?

The second diamond starts the search for solutions, and once again it starts broad. In this phase, quantity matters more than quality. The first idea is rarely the best one. It’s just the most obvious one.

Good ideas often come up when different people think together: design, development, subject-matter experts and ideally also people who will use the product later. Common formats are brainstorming, where ideas are collected first and judged later, or quick sketching rounds where everyone puts several variations on paper within a few minutes.

In the example, a two-hour workshop produces these ideas, among others:

• a short placement test before language classes,
• a “Who is this class for?” section in every class description, with examples,
• a callback service where teachers give brief advice,
• a level filter in the class search.

Only then does the team evaluate. Which idea solves the defined problem most directly? Which one can be tested with little effort? The team decides to try the new “Who is this class for?” section and the level filter first.

What you have at the end: a handful of selected ideas you want to test next.

4. Prototype and test: does it work?

Now ideas become tangible. Instead of jumping straight into code, you build a simplified version that people can already try out. There are different levels of fidelity:

• A wireframe is a simple blueprint of a page, often just in shades of gray. It shows what goes where, but not yet what it looks like.
• A prototype is a version people can interact with, from paper sketches to clickable mockups in a design tool.

You check this prototype in a usability test: people from the target group get a realistic task, such as “Find a Spanish class that matches what you already know”, and you watch where they hesitate, search or fail. The goal isn’t to confirm your own idea, but to find out where it doesn’t work yet.

In the example, testing with five people reveals two things. The “Who is this class for?” section helps a lot, but people miss it because it sits at the bottom of the page. And the level labels A1, A2 and B1 mean nothing to many people. The team moves the section to the top and adds a plain-language sentence for each level, for example “A2: You can get by in simple everyday situations.” Then it tests again.

What you have at the end: a tested, improved solution and an understanding of why it looks the way it does.

5. Launch, measure and keep learning

If the prototype holds up, the solution gets built and released. For many beginners, this feels like the end. In reality, it’s more of a checkpoint. Only in real use do you find out whether the solution actually solves the problem from phase 2.

That’s why it pays to decide before launch how you’ll recognize success. In the example, it’s the number of calls asking “Is this class right for me?” The team asks the registration staff to tally these calls for four weeks, just like in phase 1. If the number drops, the solution worked. If it stays the same, a new round begins, with a clearer picture than the first time.

What you have at the end: an answer to whether things have improved, and usually the next open question.

Three well-known models, one shared logic

As you dig deeper into UX, you’ll come across different process models. At first glance they look different, but they map neatly onto the phases above.

Double Diamond

The Double Diamond is above all a communication tool. It makes visible that the problem phase needs just as much room as the solution phase. The Design Council later expanded the model into its “Framework for Innovation”. Among other things, it adds four principles: put people first, communicate visually and inclusively, collaborate and co-create, and iterate.

Design Thinking

Design Thinking became widely known mainly through the design agency IDEO and the d.school at Stanford University. The d.school describes five modes: Empathize, Define, Ideate, Prototype and Test. The Nielsen Norman Group, a well-known UX research and consulting firm, adds a sixth phase, Implement, and groups the phases into three larger stages: understand, explore and materialize. In substance, that lines up very closely with the five steps in this article.

Human-centered design according to ISO 9241-210

Drier, but no less important, is the international standard ISO 9241-210. It describes human-centered design for interactive systems. The current edition dates from 2019 and, according to ISO, was confirmed in 2025. The standard names four activities that repeat:

1. understanding and specifying the context of use, meaning who uses a system, for what, where and under which conditions,
2. specifying the user requirements,
3. producing design solutions,
4. evaluating the design, meaning checking it with users.

On top of that come principles such as: users are involved throughout development, the design is driven and refined by evaluation, and the process is iterative, meaning it runs in repeated loops. When a project talks about “standards-compliant” or “human-centered” development, it usually refers to this standard.

Lean UX

Lean UX was popularized by Jeff Gothelf and Josh Seiden and is aimed mainly at teams working in an agile way, meaning in short, regular development cycles. Lean UX condenses the process into a small loop often described as “Think, Make, Check”: turn assumptions into hypotheses, build a small version, test it with real people. What counts isn’t extensive documentation, but what the team learns together. For more context, read Lean UX: Trend or Real Improvement?.

Lean UX also shows that the map isn’t always measured in weeks or months. A full loop can happen within a single sprint if the question is small enough.

A loop, not an assembly line

All of these models are usually drawn as a sequence from left to right. That’s handy for explaining them, but misleading in practice. The Design Council explicitly stresses that the Double Diamond is not a linear process. The Nielsen Norman Group likewise describes Design Thinking as a cycle in which teams often return to understanding after testing.

That’s exactly what happens in the adult education example. During the usability test, it turns out that several participants don’t use the class search at all, but land directly on a class page via a search engine. Nobody had noticed this in phase 1. The team briefly steps back, looks at the entry pages in the analytics and adjusts the problem statement: people need to be able to judge whether a class fits them on every single class page, not just in the overview.

Steps back like this aren’t a sign that something went wrong. They’re the actual point of the process: learn early, while changes are still cheap. Rearranging a class description in a prototype takes a few minutes. The same change after relaunch costs meetings, development time and often patience.

How big does the process need to be?

A common misconception among beginners: a UX process sounds like big teams, long projects and lots of budget. It doesn’t have to be. The map stays the same, only the scale changes.

Here’s an example of two very different sizes:

• Large project: a team of researchers, designers and developers spends several months relaunching a customer portal, with dozens of interviews, several rounds of testing and a gradual rollout.
• Small question: someone on the design team wants to find out whether a new button label in the checkout is clearer. They spend an hour reading support requests (understand), phrase the problem in one sentence (define), write three variations (ideas), show them to five people (test) and watch the drop-off rate after going live (measure).

Both follow the same logic. That’s good news, especially for small teams: you don’t need every method, just one per phase that fits your situation. What that can look like with little time and budget is covered in the book Lean UX für kleine Teams (in German), which organizes methods along the Double Diamond. How UX work fits into agile workflows is explained in How to Easily Use Agile UX in Your Project.

Common beginner mistakes

When you apply the UX process for the first time, you’ll often trip over the same spots. The good news: once you know them, you can usually avoid them.

Starting with the solution. The classic. At kickoff, it’s already decided what will be built, and research is only supposed to confirm it. In moments like these, ask politely: which problem is this solution meant to solve, and how do we know that problem exists?

Research as a box-ticking exercise. Interviews are conducted, end up in a report and never matter again. Research is only valuable if it changes decisions. A simple test: can you name a decision that turned out differently because of the findings?

Getting stuck in the first diamond. The opposite is a problem too. Some teams research for months because they’re afraid of missing something. It’s enough to know enough to write a good first problem statement. You’ll learn the rest while testing.

Skipping testing. Under time pressure, the usability test is often the first thing to go. Yet it’s frequently the cheapest way to avoid expensive mistakes. Even a short test with a few people reveals the biggest problems.

Confusing artifacts with results. A polished persona, a colorful journey map, a detailed report: these are all tools. The actual result is that something gets better for the people who use the product.

How to use the map in your next project

You don’t have to introduce a complete process model in your next project. Often it’s enough to keep the map in mind and ask the right questions at the right moments.

1. Figure out where you are. Before you start, ask yourself: do we already know the problem, or are we just guessing? Depending on the answer, you start in the first or the second diamond.
2. Write down the problem statement. One sentence is enough: who wants to achieve what, and where do they fail? Share it with the team and have them confirm or correct it.
3. Decide how you’ll recognize success. A number, a behavior, an observation. Without this criterion, you won’t know later whether the solution worked.
4. Collect more than one idea. Push yourself to sketch at least three approaches before you pick one.
5. Test early and small. A sketch you show to five people tells you more than a perfect design nobody has seen.
6. Plan for stepping back. Expect a test to raise new questions, and leave some room for that in the plan.

Conclusion

The UX process is less a fixed sequence of methods than a way of thinking: understand first, then decide, then try things out, then learn. Whether a model is called Double Diamond, Design Thinking, ISO 9241-210 or Lean UX changes little about that core.

For the adult education center, the outcome isn’t a new app, but clearer class pages with a prominent “Who is this class for?” section and explained levels. Whether that’s enough will become clear over the next few weeks. And if it isn’t, the team knows exactly where to pick up this time.

If you’re just getting started with UX, use this map for orientation. You can pick up the individual methods, from interviews to personas to usability tests, one by one. What matters is that in every project you know which phase you’re in and which question you want to answer there.

Checklist

• The problem is backed by conversations, observations or data, not just assumed.
• There’s a written problem statement that doesn’t presuppose a solution.
• A success criterion is set before the solution is built.
• Several ideas were collected before one was chosen.
• The chosen solution was tested as a prototype with real people.
• Insights from testing feed back in, even if that means stepping back.
• After launch, you check whether the success criterion has changed.

Sources

• Design Council: The Double Diamond
• Design Council: History of the Double Diamond
• Design Council: Framework for Innovation
• Stanford d.school: Design Thinking Bootleg, 2018
• Sarah Gibbons: Design Thinking 101. Nielsen Norman Group, 2016
• ISO 9241-210:2019: Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems
• NIST: Human Factors and Human-Centered Design
• Jeff Gothelf, Josh Seiden: Lean UX, 3rd Edition. O’Reilly Media, 2021
• Jonathan Follett: What Is Lean UX? O’Reilly Radar, 2017