← Go Back

Design Thinking

What is design thinking?

Design thinking is a human-centred approach to solving problems: you start by understanding people’s needs, then define the problem, generate ideas, build prototypes, and test with users. It’s iterative and collaborative, and it favours learning over guessing.

Use it when: the problem is fuzzy or the solution isn’t obvious. Use it to avoid building the wrong thing by putting user understanding and rapid testing at the centre.

Copy/paste template (five phases)

  1. Empathise – Understand users: interviews, observation, “what do they need and why?”
  2. Define – Synthesise into a clear problem statement (user, need, insight).
  3. Ideate – Generate many ideas; don’t judge yet. “How might we…?”
  4. Prototype – Make ideas tangible (sketches, click-throughs, role-play).
  5. Test – Put prototypes in front of users; learn and refine.

You’ll loop back between phases; it’s not a one-way pipeline.

Why design thinking matters

  • Reduces the risk of solving the wrong problem or building something nobody needs.
  • Creates shared understanding and alignment through empathy and evidence.
  • Encourages experimentation and learning instead of big, upfront bets.
  • Works for product, service, and process challenges.

What good design thinking includes

Checklist

  • [ ] User at the centre – research and empathy before solutionising.
  • [ ] Problem defined – a clear, actionable problem statement before ideation.
  • [ ] Diverse ideas – quantity before critique; then narrow.
  • [ ] Tangible prototypes – something people can react to, not just discuss.
  • [ ] Real user testing – feedback from the people you’re designing for, not just stakeholders.

Common formats

  • Workshop: time-boxed phases (e.g. 2-hour empathy + define; 1-hour ideate; 1-hour prototype). Good for alignment and kick-offs.
  • Project: phases over days or weeks with research and testing in between. Good for complex problems.
  • Sprint: compressed into a few days (see Design sprint).

Examples

Example (the realistic one)

Problem space: “Support gets the same questions repeatedly.” Empathise: interviews with support staff and customers; themes: customers can’t find answers, and when they do, they don’t trust them. Define: “Customers need a way to find and trust answers without waiting for support.” Ideate: 20+ ideas (better search, in-app guides, chatbot, etc.). Prototype: clickable “help centre” flow and one in-context tip. Test: 5 customers try to solve a problem; we see where they still get stuck. Loop back to define or ideate with the new insight.

Common pitfalls

  • Skipping empathy: going straight to solutions. → Do this instead: do at least some user contact (interviews or observation) before define and ideate.
  • Vague problem statement: “Users need better experience.” → Do this instead: use a problem statement format: user, need, context, evidence.
  • One idea too early: falling in love with the first concept. → Do this instead: ideate in quantity; then select and prototype.
  • No real user testing: only internal feedback. → Do this instead: test with people who match your users and aren’t on the project.
  • Treating it as a one-off: design thinking is a mindset and habit, not a single workshop. → Do this instead: embed empathy and testing in your ongoing process.
  • Design thinking vs design sprint: a sprint is a time-boxed format (often 5 days) that applies design thinking; design thinking is the broader philosophy and phases.
  • Design thinking vs human-centred design: human-centred design is the principle; design thinking is one process that applies it.
  • Design thinking vs agile: agile is about delivery and iteration; design thinking is about problem-finding and solution-finding. They complement each other (discover with design thinking; deliver with agile).

Next step

Run a short cycle: 3–5 user interviews (Empathise), write one problem statement (Define), run a 30-minute ideation (Ideate), sketch or wireframe one idea (Prototype), and test it with 2–3 users (Test). Then read Problem statement to strengthen your Define output.

Related Terms