ux process

In the middle of my career, I got hired as a UX Design Lead at an agency. Before that, I’d done UX projects as an individual contributor covering a range of work. But this was the first time I was expected to have deep knowledge not just in my specialty, wireframing and visual design, but across the entire discipline.

The problem? I didn’t have much experience in research. I’d done user interviews before, but I didn’t understand deeply why they mattered or when to implement them. I had no experience presenting to clients. And I wasn’t sure what popular design frameworks existed or what the differences between them were.

Here’s how agencies work: They have many clients with different needs, and you as a specialist are thrown into projects where you’re expected to know what to do, whether that’s designing, researching, interviewing, presenting, or strategizing. From the beginning, and every couple of months after, I was put in a position to deliver.

So I studied. I spent hours after work digging into every popular design framework I could find: Double Diamond, Design Thinking, Lean UX, Agile UX, you name it. I documented every method, mapped out every activity, and figured out how they all connected. It took me weeks to figure out what should have been clear from day one.

What I’m going to give you in this chapter is what I had to build for myself: a clear breakdown of how all the major design models work, how the methods and activities map together, and when to use what.

Why Understanding Process Matters

Here’s what I discovered after mapping out all those frameworks, and this is the insight that changed everything for me:

Every project follows a process, but most designers don’t know where they are in that process, or what to do next.

Let me tell you what happens when you don’t understand process.

You join a project mid-stream. Some research has been done. Some designs exist. But you have no idea what phase you’re in. You don’t know if you should be validating research findings, exploring new design directions, or preparing for handoff. So you guess. You ask tentative questions in meetings. You wait for someone to tell you what to do. And while you’re waiting, you feel incompetent.

Or maybe you start a new project from scratch. Your stakeholder says “we need to improve the checkout flow.” You think, “Okay… should I start by looking at analytics? Interviewing users? Reviewing the existing design? Creating wireframes?” You’re not sure, so you pick something and hope it’s right. Weeks later, someone asks “Did you validate this with users first?” and you realize you skipped a step.

Or maybe you’re asked to present your work to leadership. You show your designs. They ask, “What research informed this?” or “How did you prioritize these features?” and you don’t have good answers because you didn’t know you were supposed to do those things first.

This is what it feels like to work without understanding process. You’re constantly reactive, uncertain, and playing catch-up.

Now let me tell you what changes when you DO understand process.

You walk into any project, whether you’re joining mid-stream or starting from scratch, and you immediately know where you are. You can look at what’s been done and say, “Okay, we’re in the research phase, halfway through discovery. We need to synthesize these findings and define the problem before we start designing.”

When a stakeholder asks you to do something, you know where it fits in the process. If they say “Can you design some concepts?” and you’re still in research, you can confidently say, “Yes, but let’s finish validating our assumptions first so we’re designing the right thing.”

When priorities shift or deadlines compress, you know what can be compressed and what can’t. You know which activities are critical and which are nice-to-have.

Understanding process gives you confidence, clarity, and credibility.

And here’s the thing I discovered after studying Double Diamond, Design Thinking, Lean UX, Agile UX, and every other framework I could find:

At a high level, they’re all saying the same thing.

The Frameworks Are Different Words for the Same Journey

When I was starting out, I was confused by all the different frameworks. Why did they differ? Which one should I use? Which one was “right”?

Here’s what I realized: The nuances exist because certain approaches work better in certain industries or organizational contexts.

An agency running client projects on tight deadlines will approach UX differently than a product team iterating on the same app for years. A startup moving fast will use different language than a regulated industry that requires extensive documentation.

But underneath the different terminology, they’re all describing the same fundamental process:

• Understand the problem before you try to solve it (Research)
• Explore and test solutions to see what works (Design)
• Build and refine what you’ve validated, together with engineering (Develop)
• Monitor and improve over time (Continuous UX)

Different words. Same journey.

Once I understood this, everything clicked. I stopped worrying about which framework was “right” and started focusing on where I was in the fundamental process: Are we understanding the problem, exploring solutions, building what we’ve validated, or improving what’s live?

That simple question tells you what activities you should be doing and what comes next.

The Four Phases That Power Every Project

Whichever framework your company uses, its steps fit somewhere in these four phases, even when a framework only covers two or three of them:

• UX Research. Make sure you’re solving the right problem
• UX Design. Make sure you have the right solution
• UX Develop. Make sure what ships works the way it should, as you build and refine it with engineering
• Continuous UX. Make sure you’re improving the experience over time

Each phase contains specific categories of work, which we’ll dive deeper into in the next chapter.

And here’s the key insight: This is a cyclical, iterative process. You don’t do research once and move on forever. You cycle through these phases continuously as you learn more about your users and refine your solutions.

Let me break down each phase.

The Four UX Phases

Picture a circle divided into four quadrants, each representing a different type of work: UX Research, UX Design, UX Develop, and Continuous UX.

Here’s what each phase represents:

1. UX Research

The Research phase is about understanding the problem before you try to solve it.

Research & Discovery is where you gather insights about your users, the business, and the problem space. You’re asking questions like: Who are our users? What are their goals? What problems are they facing? What does the data tell us?

Define & Align is where you synthesize your research into a clear problem statement and get everyone on the same page. You’re answering: What problem are we actually solving? What are the user needs? What should we prioritize? How do we align stakeholders around a shared understanding?

2. UX Design

The Design phase is about creating and validating solutions.

Design & Ideation is where you explore possible solutions. You’re sketching, wireframing, prototyping, and iterating on ideas. You’re asking: What are the different ways we could solve this problem? What does the user flow look like? How should this function?

Testing & Validation is where you test your designs with real users to see if they actually work. You’re asking: Can users complete the task? Where do they get confused? What needs to change? Does this solution actually solve the problem we identified?

3. UX Develop

The Develop phase is about building and refining the experience with engineering.

Iterate is where you take feedback from testing and improve your design. You’re making adjustments based on what you learned, refining the experience as it gets built, and setting up any A/B tests you’ll run once it’s live.

Deliver is where the design becomes real. On some teams, that means handing your designs to developers. On others, designers and engineers build it together, sometimes directly in code. Either way, your job is to protect the intent, the behavior, the accessibility and the edge cases as it gets built. You’re doing design QA, creating documentation, and supporting the development process.

4. Continuous UX

The Continuous UX phase is about maintaining and improving the experience over time.

Ongoing UX is where you monitor the live product, identify opportunities for improvement, and continuously optimize the experience. You’re conducting UX audits, analyzing user behavior, and finding ways to make things better.

UX Collaboration is where you work cross-functionally to align teams, run workshops, and ensure UX thinking is embedded throughout the organization. You’re facilitating design sprints, creating service blueprints, and building bridges between teams.

Understanding Popular Design Models

You might be wondering: “How does this compare to the frameworks I’ve heard about?” Let me break down the most popular models and show you how they map to these four phases.

Double Diamond (Developed and shared by the UK Design Council in 2004) has four phases: Discover, Define, Develop, and Deliver. It’s called “Double Diamond” because it shows two cycles of divergent thinking (exploring many options) followed by convergent thinking (narrowing down to the best solution). Roughly speaking, the first diamond (Discover and Define) maps to UX Research, and the second (Develop and Deliver) maps to UX Design and UX Develop. This model is popular in service design and UK-based agencies.

Design Thinking (Popularized by IDEO and Stanford’s d.school) has five phases: Empathize, Define, Ideate, Prototype, and Test. It emphasizes human-centered design and rapid prototyping. The first two phases (Empathize and Define) map to UX Research, while Ideate, Prototype, and Test map to UX Design. This approach is popular in innovation consulting and startup environments.

Lean UX (Introduced by Jeff Gothelf and Josh Seiden in 2013) is inspired by Lean Startup methodology. This model focuses on rapid cycles of Think, Make, Check with minimal documentation. It emphasizes outcomes over outputs and moves quickly through all phases in short iterations. This is popular in agile product teams and startups where speed and learning are prioritized.

Agile UX integrates UX into agile/scrum development sprints (often one- or two-week cycles). It emphasizes doing “just enough” research and design to keep pace with fast development timelines. Many product companies use this model because it aligns UX work with engineering sprints.

Here’s the key insight: While these models use different names and slightly different structures, they all follow the same basic pattern: understand the problem, design solutions, build them, test and improve. My four-phase framework gives you a simple way to understand where you are in any of these processes and what type of work you should be doing.

How These Phases Connect

These phases aren’t meant to be followed in a rigid, linear sequence. Instead, think of them as a cycle that you move through continuously.

The cycle works like this: You start with research to understand your users and define the problem. That research informs your design work, where you create and test potential solutions. Once you’ve validated a design, you move into development to build and deliver it. After it’s live, you enter continuous UX mode: monitoring performance, gathering feedback, and identifying new opportunities. Those insights often send you back to research, and the cycle begins again.

You might spend different amounts of time in each phase depending on the project. A brand-new product might require weeks of research upfront. An optimization project might spend most of its time in Continuous UX with quick cycles back to design and testing. A tight deadline might force you to compress research and design into a single sprint.

You might also jump between phases. Testing might reveal a fundamental misunderstanding of the problem, sending you back to research. Development constraints might require you to redesign a feature. A post-launch audit might uncover issues that need immediate iteration.

It helps to think of the four phases as four questions rather than four steps. Each one asks something different. Research asks, “What do we know?” Design asks, “What are we trying, and what evidence do we have that it works?” Develop asks, “What needs to ship?” Continuous UX asks, “What did we learn?” On a fast-moving team, you might ask all four in a single day. You don’t have to finish one phase before you start the next, but you do have to answer its question before you commit.

The important thing is knowing where you are in the process, understanding what you’re trying to accomplish, and choosing the right activities to get you there. That’s what we’ll cover in the next chapter.

Research First, Design Second

Here’s one of the most important principles in UX: understand the problem before you design the solution, and let what you learn shape the design.

A lot of designers skip this without meaning to. A product manager hands over a brief with the problem and the solution already filled in, and we design exactly that, as if every assumption in it were proven. Sometimes there’s no brief at all, just “make this look good, you’re the designer.” Your job is to check the problem before you polish the answer. That matters more now, not less. When a screen takes minutes to make, the fastest way to waste that speed is to build the wrong thing beautifully.

As you can see in the order of the phases, Research typically comes before Design, and for good reason. If you skip research and jump straight to designing, you’re just making pretty pictures based on assumptions and gut feelings. You might get lucky, but more often than not, you’ll waste time building something users don’t need, don’t understand, or can’t use.

That said, the order isn’t always this tidy. Some teams build a quick prototype first and put it in front of real users to see what they do with it. That’s fine, as long as you follow the real rule, which is research before you commit. Real users get their say before your team locks in a direction or ships it to customers.

Research gives you the insights you need to design something that actually solves the user’s problem. It tells you who your users are, what they’re trying to accomplish, where they’re struggling, and what would make their lives better. Without those insights, you’re designing in the dark.

The best designers I know are obsessed with understanding their users. They treat research as the foundation of everything they do. They might do lightweight research (a few user interviews, some analytics analysis, a quick competitive review), but they never skip it entirely.

Even when deadlines are tight and stakeholders are pushing for quick solutions, good designers find a way to gather at least some user insights before committing to a direction. Because they know that an extra day of research can save weeks of designing the wrong thing.

Make research a habit, not an afterthought. Let it guide your design decisions. Test your assumptions early and often. Putting evidence ahead of assumptions is the whole of Chapter 3, where I’ll show you how to do it. And remember: the goal isn’t to create beautiful interfaces. It’s to solve real problems for real people.