Design thinking
Design thinking is a problem-solving methodology that puts user needs first, moving through five stages, empathize, define, ideate, prototype and test, before committing to a solution. It was popularized by IDEO and Stanford's d.school and is now used well beyond product design, in marketing, operations and software strategy, wherever a team faces an ambiguous problem and wants to avoid jumping straight to a fix nobody asked for.
What is design thinking?
Design thinking is a structured way to solve problems that starts with understanding the people affected by the problem, rather than starting from a proposed solution. Instead of asking "what should we build", it asks "what does the user actually need, and why". The method is non-linear: teams often loop back to an earlier stage once new information surfaces, rather than following the five stages in a strict sequence.
The five stages of the design thinking process
- Empathize: research the people affected by the problem through interviews, observation and immersion, to understand their needs, motivations and pain points.
- Define: turn that research into a clear problem statement, often framed as a "how might we" question the team can act on.
- Ideate: generate a wide range of possible solutions through brainstorming, without filtering ideas too early.
- Prototype: build a low-cost, low-fidelity version of the most promising ideas, just enough to make them tangible.
- Test: put the prototype in front of real users, collect feedback, and feed it back into an earlier stage if needed.
Key methods and deliverables at each stage
Each stage relies on its own set of tools. Empathize draws on user interviews, contextual observation and empathy maps. Define produces personas and problem statements. Ideate uses brainstorming, "how might we" prompts and affinity mapping to organize ideas. Prototype ranges from paper sketches to clickable wireframes in Figma. Test relies on usability testing sessions and structured feedback forms. None of these deliverables is the end goal in itself, they exist to move the team closer to a validated solution grounded in real evidence rather than internal opinion.
Design thinking vs UX design
| Aspect | Design thinking | UX design |
|---|---|---|
| Scope | General problem-solving methodology, usable outside digital products | Discipline focused on the usability of a digital product |
| When used | Early, to frame an ambiguous problem | Throughout a product's life, from research to shipped interface |
| Output | A validated problem statement and concept direction | Wireframes, mockups and a shipped interface |
| Relationship | Often used to kick off a UX design project | Often picks up where design thinking's prototype stage leaves off |
Best practices and common pitfalls
Timebox each stage so the process moves forward instead of stalling in research or ideation. Involve a cross-functional team, not just designers, so technical and business constraints surface early rather than after a prototype is built. Keep real users in the loop at every stage, not only during testing. The most common pitfall is treating design thinking as a one-off workshop with sticky notes: without a follow-through into prototyping and testing, the empathy and ideation work never gets validated. Another is skipping straight to ideation because the team already "knows" the problem, which usually reintroduces the exact assumption the method was meant to challenge.
Why design thinking pays off
Catching a wrong assumption during the empathize or define stage costs a few interviews. Catching it after the product ships costs a rebuild, a missed launch window and a team's trust in the roadmap. Design thinking front-loads that cost where it is cheapest to pay, and gives a team a shared, evidence-based problem statement to align on before anyone writes a line of code or a single mockup.
Design thinking at BeBranded
We use design thinking to open a project when the brief itself is uncertain: which audience, which feature, which positioning. It feeds directly into the design work that follows, so the mockups we produce answer a validated need rather than a guess.