What is Design Thinking? The 5 Stages Explained

TL;DR: What You Will Learn

• Design thinking is a human-centred problem-solving framework that reduces the risk of building things nobody wants.
• It moves you from guessing to knowing by grounding decisions in real user research.
• It runs across five stages: Empathise, Define, Ideate, Prototype, and Test.
• The process is iterative, not linear, so you loop back and refine as you learn.
• Anyone can use it: product teams, founders, marketers, and public sector officers alike.

What Design Thinking Really Means

When people first hear the term, they assume it belongs to designers alone. It does not.

Design thinking is a non-linear, human-centred framework for solving problems by starting with the people you are solving for, not the solution you already have in mind.

The approach was popularised in the 1990s by the global design firm IDEO, as IDEO’s own CEO at the time, Tim Brown, traced in his influential Harvard Business Review article “Design Thinking” (2008), and was formalised into a teachable method at Stanford’s Hasso Plattner Institute of Design, known as the d.school, founded in 2005. Their big contribution was proving that this way of working applies far beyond product design.

I have seen it used to redesign government services, shape public policy, and plan marketing campaigns. In Singapore, teams under the Municipal Services Office have applied human-centred principles to simplify how residents report town issues. The OneService app auto-routes each report to the right agency instead of making residents figure out who to contact, so that a frustrated resident is not bounced between agencies.

The Core Mindset

At its heart, design thinking is a mindset before it is a process. Three habits define it: empathy, experimentation, and a bias to action.

Empathy means you observe and listen before you assume. Picture a bank’s product team trying to improve app onboarding: instead of guessing why users drop off, they watch real customers fumble through the first screens.

Experimentation means you test rough ideas cheaply instead of debating them in meetings. A bias to action means you would rather build a scrappy paper prototype today than write a perfect specification next month.

Why It Is Iterative, Not a Checklist

Here is where most beginners get it wrong. Design thinking is a loop, not a to-do list you tick off once.

Contrast this with waterfall thinking, where you gather all requirements, design everything, build it, then launch, each step handed over like a baton with no going back. If you discover a flawed assumption at the end, you are stuck.

Design thinking assumes you will be wrong at first, so it builds in returns. You might test a prototype, learn your understanding of the user was off, and jump back to redefining the problem.

For that hypothetical onboarding team, a single user test might reveal the real pain point was not the sign-up form at all, but the identity verification step. That insight sends them looping back rather than pushing forward.

Who Actually Uses It

The people applying design thinking rarely have “designer” in their job title.

• Product managers use it to decide what to build next.
• Civil servants use it to redesign citizen-facing services.
• Marketers use it to understand why a campaign is not landing.
• Educators and HR teams use it to redesign learning and hiring experiences.

Understanding this human-centred foundation also helps clarify related craft distinctions, such as the difference between UI and UX, which sit inside this broader way of thinking.

So think of design thinking as the operating philosophy, and the five stages that follow as its practical spine. The rest of this article walks through those stages one by one, so you can apply them to whatever problem sits on your desk.

Why Design Thinking Matters for Teams and Businesses

Let me be blunt about the real cost of skipping this work. Design thinking matters because it stops you from spending six months and a big budget building something nobody actually wants.

I have watched teams pour engineering hours into a feature that looked impressive in a roadmap deck, only to see it ignored after launch. The problem was never the code. It was that nobody had spoken to a real user first.

The Cost of Skipping Empathy

When you skip the empathy stage, you are guessing. And guessing is expensive.

Imagine a Singapore fintech startup that assumes hawkers want a slick mobile dashboard. They build it, launch it, and hear crickets. A few conversations at the stalls would have revealed that most vendors just want faster QR settlement and a receipt they can show their accountant.

The cost of change rises the further you go. Fixing a wrong assumption in a sketch takes an afternoon. Fixing it after launch takes a rebuild, a re-marketing spend, and a dent in your reputation.

This is why design thinking is framed as risk reduction, not a creativity workshop. You validate cheaply and early so the expensive stages are pointed in the right direction.

Aligning Cross-Functional Teams

The second benefit is one I feel every time I run a project: it gets product, marketing, and engineering into the same room, looking at the same user.

Without a shared understanding, marketing promises features engineering never scoped, and product prioritises based on the loudest stakeholder rather than evidence. Design thinking replaces those turf battles with a common artefact everyone agrees on, like a user journey map or a validated problem statement.

When your marketer, developer, and product owner all watched the same customer struggle to complete checkout, the debate stops. Everyone knows what to fix first.

The measurable payoffs show up as:

• Fewer failed launches because assumptions are tested before the build begins
• Stronger user retention because the product solves a real, felt need
• Faster decisions because teams argue over evidence, not opinions

The Singapore Business Case

This is not just Silicon Valley thinking. It is being actively pushed here.

Enterprise Singapore supports design and innovation efforts to help SMEs move beyond cost competition toward human-centred products. IMDA’s SMEs Go Digital programme similarly nudges smaller firms to design for actual user behaviour rather than digitising a broken process

For an SME owner, that support matters. A retail business rethinking its e-commerce flow through design thinking is far more likely to see repeat purchases than one that copies a competitor’s layout.

It also explains why this skill set is valued in the job market, as reflected in the UX designer salary figures in Singapore. Businesses pay for people who can reduce the risk of building the wrong thing.

Stage One: Empathise With Your Users

The first stage of design thinking is where most teams either build something people love or waste months building something nobody wants.

Empathise means putting your own opinions on the shelf and genuinely understanding the people you are designing for: their real needs, their frustrations, and the messy context they live in.

I always tell my workshop groups the same thing: you are not here to prove your idea is good. You are here to find out what is actually true.

User Interviews and Contextual Inquiry

The fastest way to understand someone is to talk to them where they work and live, not in a sterile meeting room.

Contextual inquiry means you go to the source. In one workshop I ran, we tasked teams with designing a food ordering app for hawker stalls, so we sent them to interview actual hawker stall owners during the lunch rush.

What they learned in fifteen minutes on site beat any survey. One uncle explained he could not stop to tap a screen when he had a queue of twenty people, something no one had assumed sitting in the classroom.

When you run interviews, ask open questions and then stay quiet. Silence makes people fill the gap with the honest detail you actually need.

A quick note on the law: under the PDPA, if you record interviews or collect names, numbers, or photos, you must tell participants why you are collecting it and get their consent. Anonymise your notes and only keep what you genuinely need.

Empathy Mapping

Once you have raw notes, you need a way to make sense of them. An empathy map is the simplest tool I know.

You divide a wall or whiteboard into four quadrants and fill each with observations about one specific user.

• Says: Direct quotes you heard, like “I don’t have time to learn a new system”
• Thinks: What they seem to believe but may not say out loud
• Does: The actions and habits you watched them perform
• Feels: The emotions driving them, such as anxiety about losing regulars

The gap between what people say and what they actually do is often where your best insight hides.

Capturing Pain Points Without Proposing Solutions

Here is the discipline that separates good empathy work from lazy assumptions: capture the problem, resist the fix.

The moment you write “we should add a big button,” you stop listening. Instead, note the pain point as the user experienced it: “the owner missed three orders because the notification sound was too quiet in a loud environment.”

Keep your solutions in a separate parking lot list. You will need them later, just not now.

You can run this tomorrow. Pick three real users, spend twenty minutes with each, and fill an empathy map from what you heard, not what you hoped.

If you are moving into a UX career, understanding empathy deeply matters, and it shows up in the UX designer interview questions hiring managers ask.

Strong empathy data becomes the fuel for Stage Two, where you turn all these observations into a sharp problem statement.

Stage Two: Define the Right Problem

After all the interviews and observation from the empathy stage, you end up with a mountain of sticky notes, quotes, and screenshots. The Define stage is where you turn that raw material into one sharp, actionable problem statement, and getting this right is what stops you from wasting weeks ideating on the wrong thing.

The trap I see most often in design thinking workshops is a problem framed as a hidden solution. “Users need a bigger Buy button” is not a problem; it is a guess. Your job here is to sit with the mess a little longer before you leap.

Affinity Mapping To Cluster Insights

Affinity mapping is dead simple: write every observation on its own note, then group notes that feel related until themes emerge.

Picture a Singapore SME running a homeware e-commerce store worried about checkout abandonment. Their notes might cluster into themes like “surprised by shipping cost at the last step”, “unsure if PayNow is accepted”, and “form asks for too much before showing total”.

Suddenly the story is not “our button is wrong”. It is a trust and transparency problem surfacing only at the final step. That reframing changes everything downstream.

Crafting a Point-Of-View and How Might We Questions

A point-of-view (POV) statement locks that insight into a human sentence. I use this template with every team I coach:

[User] needs [need] because [surprising insight].

For the homeware store: “A price-conscious shopper in Singapore needs to see the full delivered cost early because unexpected shipping fees at checkout feel like a bait-and-switch.”

From that POV, you generate How We Might questions, which open up ideation without prescribing an answer. For example: “How might we make total delivered cost visible before the final step?” and “How might we reassure shoppers that PayNow and local payment options are supported?”

Notice these invite many solutions rather than one. That is the point.

Creating Personas

A persona keeps the whole team designing for a real person instead of a vague “user”. Give them a name, a context, and a genuine frustration drawn from your research, not from imagination.

For a polyclinic reframing patient queue frustration, a persona might be “Auntie Lim, 68, arrives early to avoid crowds but cannot tell how long her wait will be, so she skips her toilet break and feels anxious the whole time.”

That single line reframes the problem. The pain is not the queue length itself; it is the uncertainty of not knowing when her number is up.

When you can point at Auntie Lim and say, “Does this idea reduce her anxiety?”, every later decision gets easier. A well-defined problem is the quiet foundation that saves you from expensive, off-target ideation later.

Try this before your next planning meeting: take your last five customer complaints and turn them into one POV statement and two How Might We questions. If your team argues over the wording, that argument is more useful than skipping straight to solutions.

Stage Three: Ideate Bold Solutions

Once you understand the problem, the temptation is to jump straight to the first workable fix. Design thinking asks you to resist that urge and generate a wide range of ideas first, before you narrow down to what you will actually build.

This is the heart of the Ideate stage: divergent thinking, then convergent thinking.

Divergent thinking means opening up and producing as many possibilities as you can, no matter how odd. Convergent thinking is the deliberate act of clustering, comparing, and filtering those ideas down to a promising few.

Picture a fintech squad in Singapore trying to simplify PayNow onboarding for elderly users. Instead of debating one login screen, they spend the first half of the workshop flooding the whiteboard with dozens of ideas, then spend the second half choosing which three to test.

Set The Ground Rules Before Anyone Speaks

Good ideation dies without psychological safety, so I always agree on a few rules before the first sticky note goes up.

• Defer judgment: No idea gets shot down during the divergent phase, even the impractical ones.
• Go for volume: Aim for quantity, because the tenth idea is often better than the first.
• Build on others: Treat a teammate’s half-formed thought as a launchpad, not a finished proposal.

For the PayNow onboarding team, that means a junior designer can suggest voice-guided setup for elderly users without a senior engineer immediately listing the technical hurdles. The critique comes later.

Use Techniques to Break Out of Obvious Answers

Left to our own devices, most of us keep circling the same few ideas. Structured techniques force fresh angles.

Crazy Eights is my go-to warm-up: everyone folds a sheet into eight boxes and sketches eight distinct ideas in eight minutes. The speed stops your inner critic from taking over.

SCAMPER pushes you to Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, or Reverse parts of an existing solution. For our fintech squad, Eliminate might spark the idea of removing the OTP step entirely for trusted devices.

The worst possible idea is my favourite for a stuck room. Ask the team to design the most confusing PayNow flow imaginable, then flip each terrible feature into its opposite. It relaxes everyone and surfaces real insights.

If your team sketches these ideas in Figma, grab some of the best Figma templates to kickstart your designs so nobody wastes the session fiddling with layouts.

Converge And Pick What to Prototype

Now you switch modes. Cluster similar ideas, then run a quick dot voting round where each person gets three dots to place on their favourites.

For sharper decisions, plot the shortlist on an impact-effort matrix: high-impact, low-effort ideas go first. A voice-guided setup might be high impact but high effort, so the team parks it and picks a simpler large text confirmation screen to test now.

The goal is not consensus on the perfect answer, but a small handful of promising ideas worth prototyping. End the session by naming two or three concepts you will build into rough prototypes next.

Stage Four: Prototype to Learn Fast

By the time you reach prototyping, you have a mountain of ideas from the previous stage. Now you need to make them real enough to test, and cheap enough to throw away.

That last part matters. A prototype in design thinking is not your final product. It is a quick, disposable version of an idea built to answer one specific question.

I always tell teams to treat their prototypes as learning tools, not deliverables. The moment you get attached to a prototype, you stop listening to what users are actually telling you.

Choosing The Right Fidelity For The Question

Fidelity simply means how polished and realistic your prototype looks. Low-fidelity means paper sketches, sticky notes, and rough wireframes. High-fidelity means clickable mock-ups in a tool like Figma that look close to the real thing.

The mistake I see most often is jumping straight to high fidelity because it looks impressive. But polish is expensive, and you only need as much of it as your question demands.

If you are testing whether people understand the order of steps in a flow, paper is perfect. If you are testing whether a button colour or a specific micro-interaction feels right, then a clickable prototype earns its keep.

Picture a small retail startup in Singapore preparing to launch a self-checkout kiosk in their store. Before spending a single dollar on development, the team sketches the entire checkout flow on paper: scan item, weigh produce, apply a promo code, pay.

They sit real shoppers down, slide paper screens across the table, and watch where people hesitate. Within an afternoon, they discover that customers cannot find where to scan a loyalty QR code. That is a problem worth catching now, not after the software is built.

Prototype Only What You Need to Test

You do not need to build the whole product. Build the one part that carries the risk.

If your risky assumption is the loyalty step, prototype the loyalty step. Leave the payment screen as a rough placeholder for now. This keeps your effort focused and your feedback clean.

Once that team is confident in the flow, they might rebuild the key screens as a clickable Figma prototype for a second round of testing. If you are new to the tool, this step-by-step Figma tutorial for beginners will get you making interactive mock-ups quickly.

The Fail-Fast Mindset That Saves Budget

Failing on paper costs a marker and an hour. Failing after launch costs your development budget and your reputation.

So welcome the awkward moments in testing. Every confusing screen you catch on a sketch is money and rework you never have to spend later.

The goal here is not to be right. The goal is to learn fast, cheaply, and often.

Try this: before your next build, spend thirty minutes sketching the riskiest screen on paper and show it to two colleagues outside the project. If they hesitate anywhere, you’ve just found your first fix for free.

Stage Five: Test, Iterate, and Improve

This is where the theory meets reality. Testing is the stage in design thinking where you put your prototype in front of real users and watch what actually happens, rather than what you hoped would happen.

The most important shift here is emotional. You have to want to find flaws, not defend your work. A rejected idea at this stage costs you a few hours; a rejected feature after launch costs your team weeks.

Picture a Singapore e-commerce team redesigning a mobile checkout because too many shoppers abandon their carts at the payment step. Before pushing anything live, they run moderated tests with real customers to see where the friction lies.

Planning and Running a Usability Test

You do not need a lab or fancy equipment. You need five or six users who resemble your real customers, a working prototype, and a clear set of tasks.

Keep the session focused on behaviour, not opinion. Instead of asking “Do you like this checkout?”, give the participant a task like “You have added a pair of shoes to your cart. Complete your purchase using PayNow.”

Here is a simple test script structure you can reuse for almost any product:

1. Warm-up: Two friendly questions to relax the participant and learn their context.
2. Tasks: Three to five realistic scenarios, one at a time, no hints.
3. Think-aloud prompt: Ask them to narrate what they are doing and expecting.
4. Follow-up: Open questions about anything that surprised or confused them.
5. Wrap up: Thank them and note any last comments.

For the checkout team, watching one user hesitate for ten seconds looking for a guest checkout option tells you more than any survey ever could.

Capturing Findings Objectively

The hardest part is recording what you see without twisting it to fit what you already believe. Note the observable behaviour first, then your interpretation second.

Write down the exact moment someone struggled, the words they used, and where they gave up. “Three of five users tapped the back button on the delivery screen” is a fact; “the delivery screen is confusing” is a conclusion you earn from those facts.

I usually have a second person taking notes so the facilitator can stay present. If you are hiring for these roles, being able to describe findings cleanly matters, and it is one reason why most UX designer job applications get rejected comes down to weak, vague reasoning rather than pretty screens.

Feeding Results Back Into Earlier Stages

Here is where design thinking stops being a straight line. Your test rarely ends by shipping the prototype as is.

If the checkout team discovers users abandon because they do not trust the payment options shown, that is not a prototype problem. That sends them back to Empathise to understand the trust concern, or to Define to reframe the problem entirely.

Sometimes you loop back to Prototype and tweak a button. Sometimes you loop back further because you were solving the wrong problem all along.

Treat each round as a learning cycle, not a verdict. The e-commerce team might run two or three quick rounds, refining the checkout flow each time, before they are confident enough to launch to their full customer base.

Try this: Book five 20-minute sessions this week with real users, not colleagues, using the script structure above. One afternoon of honest feedback beats another week of internal debate.

Running a Design Thinking Workshop

Reading about design thinking is one thing. Standing in front of a room and actually facilitating it is another, and the first attempt is where most people freeze.

I have run these sessions for local SMEs, and the good news is that a solid workshop is mostly about preparation, not charisma. Get the setup right, and the room does the work for you.

Planning Your Session

Start with a clear goal written as a single sentence. Something like “improve the onboarding experience for our new mobile app users” beats a vague brief like “make things better”.

For a half-day sprint in an SME upskilling under SkillsFuture, I aim for six to nine participants and mix the departments deliberately. Put marketing, operations, and product staff at the same table so you get customer instinct, delivery reality, and feature knowledge in the same conversation.

Time-box everything and protect your materials list. For in-person sessions, I bring sticky notes in three colours, thick markers (fine pens make people write essays), a wall or whiteboard, and a visible countdown timer.

For remote or hybrid groups, I run the whole thing on Miro or FigJam, with a template already built before anyone logs in. If your team is heading toward product design work, it helps to understand what Figma is used for in design teams and real projects, since FigJam sits inside that same ecosystem.

A Sample Half-Day Agenda

Map your activities directly to the five stages so nobody loses the thread.

Here is a rough flow I use for a three- to four-hour session:

1. Empathise (30 min): Share real customer quotes or support tickets, then have each person write observations on stickies.
2. Define (20 min): Cluster the stickies and agree on one “How might we” problem statement together.
3. Ideate (40 min): Silent brainstorming first, then group sharing, then dot voting to shortlist ideas.
4. Prototype (45 min): Sketch the top idea as a rough paper wireframe or a low-fidelity FigJam flow.
5. Test (30 min): Walk another table through the prototype and capture honest feedback.

Leave buffer time and a break. A rushed test stage teaches the group nothing.

Keeping Energy Up and Avoiding Pitfalls

The most common mistake I see is the loudest person hijacking ideation. Silent writing before discussion fixes this instantly, because the quiet operations manager gets equal airtime with the confident marketer.

Never skip the empathise stage to “save time”. Groups that jump straight to solutions end up building for themselves, not the customer.

Watch the post-lunch slump around the prototype stage. I switch people from sitting to standing, split them into pairs, and give a firm ten-minute countdown to force momentum.

For remote sessions, energy fades faster, so keep video on, call on people by name, and use FigJam reactions to keep interaction visible. End by assigning one clear owner to each next step, or the whole session evaporates by Monday.

Common Pitfalls and How to Apply Design Thinking Well

I have watched plenty of capable teams learn design thinking in a workshop, feel energised for a week, then quietly slip back into old habits. The problem is rarely the method. It is how they apply it.

Let me walk you through where things usually go wrong, and what to do instead.

Treating The Stages as a Rigid Checklist

The five stages are not a linear queue you tick off once. Teams that treat Empathise, Define, Ideate, Prototype and Test as a one-way conveyor belt end up locked into early assumptions.

The fix is to loop back. If testing reveals you misread the user, return to Empathise or redefine the problem. Design thinking is iterative and evidence-led, not a straight line.

Skipping Empathy and Ideating Without a Defined Problem

I have seen a Singapore logistics SME rush to add a live tracking feature to its customer app because a competitor had one. Nobody spoke to actual customers first.

They ideated hard, built a polished feature, and launched. After launch, users complained it was confusing, and drivers could not update statuses reliably. The team had to rebuild the whole flow, costing months and eroding trust with their B2B clients.

Two failures caused this. They skipped genuine empathy, and they ideated without a clear, well-framed problem statement. A single afternoon interviewing five real customers and two drivers would have reshaped the entire brief.

Prototyping Too High-Fidelity Too Early, and Testing With The Wrong Users

That same SME made a third mistake: they jumped straight to production-quality code. When feedback demanded change, throwing it away hurt because so much had been invested.

Prototype cheap and rough first. A paper sketch or a clickable wireframe costs almost nothing to bin, so you feel free to be honest about what is failing.

Here is a quick checklist I use to sanity check any project:

• Have we spoken to real users, not just internal stakeholders, before defining the problem?
• Is our problem statement specific enough to guide ideation?
• Is our prototype fidelity matched to how confident we are- low fidelity when uncertain?
• Are we testing with genuine target users, not colleagues who already understand the product?
• Have we planned at least one loop back into an earlier stage?

Testing with the wrong users is subtle. Colleagues nod politely and fill gaps with their own knowledge, so you get false confidence.

Embedding it Into Everyday Habits

The biggest fix of all is to stop treating design thinking as a one-off workshop event. Fold small habits into weekly rhythms: a standing user interview slot, a shared problem statement pinned to every project brief, and a rule that no build starts without a tested prototype.

These habits only stick when your team has real, documented skills rather than a vague memory of a workshop, which is why structured, hands-on training makes such a difference.

Conclusion

At the start of this article, I described that sinking feeling every team knows: you ship something you were proud of, and users barely touch it. You built the wrong thing.

Design thinking is the antidote to that, because it forces you to stay close to real people before you commit time and budget to a solution. Instead of guessing, you empathise, define the real problem, ideate widely, prototype cheaply, and test with actual users.

The most important thing I want you to take away is this: it is not a one-time workshop you do once and tick off. It is a repeatable, human-centred loop you keep running as you learn more.

The five stages work precisely because they are cyclical. A test result sends you back to redefine the problem. A messy prototype reveals an assumption you never questioned. That is the framework doing its job, catching the wrong thing before it becomes an expensive mistake.

So here is my challenge to you for this week. Do not wait for a big project or a formal mandate. Pick one small, nagging problem your team keeps arguing about, gather three colleagues, and run a ninety-minute session covering empathy and define, then sketch a few rough ideas on paper. Keep it scrappy. Keep it real.

That first small workshop is how the habit starts, and habits are what turn a nice concept into how your team actually works.

If you want to go deeper and build the structured, hands-on skills that make you genuinely employable in this field, the UX/UI Design Career Programme is the logical next step. It takes you through the full design and UX process with real projects, so you finish with portfolio-ready work and the confidence to lead these sessions yourself.