UX/UI Design, A to Z ┃ 1.3 Design Thinking

Welcome back! How’s your day going?

In the last lesson, we looked at how UX drives business results. Today, we're going one level deeper — into the process design teams actually use to get there.

It's called Design Thinking. And by the end of this lesson, you'll understand not just what the steps are, but why each one exists.

Let's go.

What Is Design Thinking?

Design Thinking is a mindset and methodology for solving problems by putting the user at the center.

Here's what makes it different. Most teams start from a solution they've already decided on. Design Thinking refuses to do that. Instead, it starts by understanding what people actually need, what situations they're in, and what's making their lives harder.

Only then does it define the problem, explore possible solutions, and refine them through prototyping and testing.

The basic flow looks like this:

Understand users → Define the problem → Explore ideas → Build prototypes → Test and improve

Actually, Design Thinking isn't just for designers. Product managers, developers, marketers, founders — anyone who has to solve a problem involving real people can use it.

Why Do We Need It?

Here's the trap almost every organization falls into: they start building solutions before they understand the problem.

Picture this. Users aren't engaging with your service. The company's conclusion? "We must be missing features. Let's build more."

But then you run some user research — and the real cause turns out to have nothing to do with features. The menu structure is confusing. The instructions are hard to follow. People aren't asking for more; they're struggling with what's already there.

This is why problem definition matters so much. If you define the problem wrong, even a beautifully executed solution solves nothing.

So Design Thinking begins by asking:

• What problem are users actually experiencing?
• What situations and causes produce that problem?
• Is the problem we're trying to solve genuinely important?
• Will this solution actually help?
• Can it serve user value and business goals at the same time?

In other words, Design Thinking isn't a method for generating good ideas. It's a process for finding the right problem — and then validating that your solution actually solves it.

The Double Diamond

The most widely used framework for visualizing Design Thinking is the Double Diamond, introduced by the UK Design Council in 2005.

It has four stages:

Discover → Define → Develop → Deliver

And the two diamonds represent two very different jobs:

• The first diamond: finding the right problem
• The second diamond: finding the right solution to that problem

Why diamonds? Because of the shape each phase makes. Inside each diamond, you first expand — then you narrow. This expansion and contraction happens twice, and understanding it is the key to understanding the whole model.

Let's break down those two movements.

Divergent Thinking: Go Wide

Divergent thinking means resisting the urge to lock onto one answer, and instead exploring the full range of possibilities.

When you're exploring the problem, this means investigating different users, different situations, different possible causes. When you're exploring solutions, it means generating as many ideas and approaches as you can.

The core discipline here is simple: don't judge too early.

In practice, divergence looks like:

• Interviewing different types of users
• Observing people in their actual environment
• Digging into multiple possible causes of a problem
• Generating many different solution ideas
• Questioning assumptions and "the way we've always done it"

And here's the point that's easy to miss. The goal of divergence isn't to collect as much information as possible. It's to build up enough possibility that your next decision can be a good one.

Convergent Thinking: Narrow Down

Convergent thinking is the opposite movement: taking everything you gathered and narrowing it down based on evidence and criteria.

You can't treat every problem and every idea as equally important. So the team has to select — the problems that matter most, and the solutions most likely to work.

Useful criteria for narrowing down:

• Impact on users — how much does this affect people?
• Frequency — how often does it happen?
• Severity — how bad is it when it does?
• Business value — does solving it matter commercially?
• Technical feasibility — can we actually build it?
• Time and cost — what will it take?
• Risk — what could go wrong?

And the single most important rule of convergence: decide based on research and verifiable evidence, not on personal taste or the loudest opinion in the room.

That's a harder discipline than it sounds. It's also what separates professional design work from decoration.

The Four Stages, One by One

1. Discover — Understand the Situation

Discover is the starting line.

The goal here is to understand the current situation from the user's point of view, and to explore the problem space broadly. Crucially, the team does not assume it already knows the cause. It goes and gathers evidence from real users and real data.

Common research methods:

• User interviews
• Field observation
• Surveys
• Usage data analysis
• Reviewing customer complaints and support tickets
• Competitive research

Through these, you're identifying users' behaviors, goals, motivations, needs, and pain points.

Discover uses two kinds of data together, and understanding the difference matters:

• Qualitative data tells you what people experience and why they behave the way they do. (Interviews, observation.)
• Quantitative data tells you how often and at what scale something happens. (Analytics, surveys.)

You need both. Qualitative data without quantitative data risks over-weighting one loud voice. Quantitative data without qualitative data tells you what is happening but never why.

The key question: What are users experiencing, in what situations, and what's making it hard for them?

What you produce: user needs · pain points · behavior patterns · user context · early insights

2. Define — Sharpen the Problem

Define is where you analyze everything you gathered and crystallize the core problem worth solving.

This is not just listing complaints. You're looking for recurring patterns and root causes — and deciding which problem to tackle first.

To evaluate and prioritize problems, use criteria like:

• User impact
• Frequency
• Severity
• Business viability
• Technical feasibility

The output of this stage is usually a problem statement — one or two sentences that frame the challenge. For example:

New users struggle to understand the instructions during sign-up and abandon the process partway through. They need clearer guidance to complete registration.

A good problem statement answers four things:

• Who is experiencing the problem?
• What do they need to accomplish?
• When/where does the problem occur?
• Why does this matter?

And here's the discipline that trips up almost every beginner: do not decide on a solution while defining the problem.

Notice that the example above doesn't say "we should add a tooltip" or "let's redesign the form." The moment you bake a solution into your problem statement, you've narrowed your exploration before it even began. A well-written problem statement stays open — it invites many possible answers.

The key question: What is the most important user problem we should solve first?

What you produce: problem statement · prioritized user needs · core insights · a clear design challenge

3. Develop — Explore Solutions

Now — finally — you generate solutions.

Develop is where the team explores many possible ways to solve the defined problem. And notice the plural: the goal is not to pick one perfect solution immediately. It's to create a range of possibilities you can compare and test.

Typical activities:

• Brainstorming
• Ideation workshops
• Sketching
• Designing user flows
• Concept development
• Wireframing
• Early prototypes

The question that drives this stage:

How might we solve this user problem?

Once you've generated enough ideas, you converge again — evaluating each option against:

• Value delivered to users
• Likelihood of actually solving the problem
• Technical feasibility
• Cost and time
• Alignment with product and business strategy
• Anticipated risk

The key question: What are the possible ways to solve this problem?

What you produce: solution concepts · user flows · sketches and wireframes · early prototypes · candidate ideas to validate

4. Deliver — Build, Test, Refine

Deliver is where the most promising solutions take real shape — and get put in front of real users.

The team builds prototypes and has actual (or target) users try them. During testing, you're watching for three things: Can they complete the task? Where do they get confused? Does this actually solve the original problem?

Typical activities:

• Prototyping
• Usability testing
• Gathering user feedback
• Design refinement
• Accessibility review
• Technical validation
• High-fidelity screen design
• Handoff to development

And when testing reveals problems, you fix the design and test again. A solution is never finished after one round of testing. It gets sharper through repeated validation.

The key question: Does this solution actually solve the user's problem in the real world?

What you produce: validated user-centered solution · final designs · design specs for implementation · test results pointing to future improvements

Design Thinking Is a Loop, Not a Line

Here's the thing most beginners get wrong about the Double Diamond: it is not a checklist you complete once, in order, and then you're done.

Design Thinking is fundamentally iterative and flexible. When new information surfaces, you go back.

For instance:

• Usability testing reveals your problem definition was wrong. → Back to Define.
• A prototype test uncovers a user need nobody knew about. → Back to Discover.
• A technical constraint blocks your solution. → Back to Develop.
• Post-launch feedback changes the direction entirely. → Back to wherever the evidence points.

So you might go from Deliver back to Develop. Or all the way back to Define, or even Discover.

And this is the mindset shift that matters most:

Going backwards doesn't mean the process failed. It means you learned something.

Every loop back is the process working exactly as designed — using new evidence to make the problem and the solution more accurate.

The Five-Stage Model (And How It Relates)

You'll also frequently see Design Thinking described in five stages:

Empathize → Define → Ideate → Prototype → Test

If you're now wondering "wait, which one is correct?" — good news. These are not two competing processes. They're two different views of the same thing.

Here's how they map onto each other:

So which should you use? It depends on what you're trying to see:

• The five-stage model is better for understanding the specific UX activities you perform at each step.
• The Double Diamond is better for understanding the overall structure — how you expand and contract, twice, across problem and solution.

Most teams use the vocabulary of both, interchangeably. Now you'll know what they mean either way.

Key Takeaways

Let's pull it all together.

The Double Diamond in one line:

The left diamond is about finding the right problem. The right diamond is about solving that problem right.

And here's what Design Thinking does for a team:

• It grounds decisions in users and data, not guesses and assumptions.
• It stops you from committing to one idea too early — you explore many first.
• It validates solutions with real users, instead of trusting your instincts.
• It treats going back as progress, not failure.

If you remember one sentence from this entire lesson, make it this: Explore broadly. Choose with evidence. Validate quickly. Improve repeatedly.

That's the whole process, compressed.

Before You Go

Here's a small exercise to make this real.

Think of one thing that frustrates you about an app or service you use regularly. Now, instead of jumping to a fix, write a problem statement using the four elements from the Define stage:

[Who] struggles with [what] when [situation], and needs [what outcome].

For example:

Commuters struggle to know when their bus will actually arrive when the app shows only scheduled times, and need real-time accuracy to plan their morning.

Then check yourself: did you sneak a solution into it? If your statement contains words like "needs a notification feature" or "needs a redesigned map," go back and rewrite it. Describe the need, not the fix.

That one discipline — separating the problem from the solution — is what most beginners never learn, and what every good designer practices every day.

In the next lesson, we'll look at Brand Experience(BX) — what it actually means, and why it starts long before someone opens your app.

Follow this blog to get every new lesson as soon as it's published — plus practical UX insights and career resources, all free.

Thank you.😊