Design Thinking

Learn about people in context, frame a useful problem and use low-cost prototypes to learn before committing to a full solution.

In one minute

Design Thinking is an iterative way to approach ambiguous problems. A commonly taught Stanford d.school model uses five modes:

1. Empathise: study what people do, need and struggle with.
2. Define: turn observations into a focused point of view.
3. Ideate: create meaningfully different solution options.
4. Prototype: make assumptions tangible at low cost.
5. Test: observe how people respond and revise the problem or solution.

The modes are not a one-way pipeline. Test evidence may send the team back to research or reframing.

Best for: unclear customer or employee problems, new services, experience redesign and early product concepts.
Avoid when: the problem and remedy are already verified, immediate incident containment is required or the team cannot access relevant users.

The problem it addresses

Teams often begin with a preferred solution and then search for support. This creates expensive products that work technically but solve a weak, misframed or low-priority problem.

Design Thinking creates a disciplined learning loop between real-world behaviour and solution decisions. Its intended output is not a brainstorm. It is a tested concept and a clearer account of what remains uncertain.

When to use it

Use Design Thinking when:

• people work around an existing service in surprising ways;
• several stakeholders describe the problem differently;
• current research explains satisfaction but not behaviour;
• a new concept needs evidence before engineering investment;
• the experience crosses product, service and operational boundaries;
• the team needs alternatives rather than incremental feature requests.

A useful starting question names a person, a situation and a desired change without embedding a solution.

When not to use it

Do not use it:

• instead of emergency containment or compliance action;
• to avoid quantitative, technical or financial analysis;
• when a decision has already been made and research is only ceremonial;
• when “users” are represented entirely by internal opinions;
• for a stable, well-specified implementation problem that needs project planning;
• as a single workshop with no route to testing or ownership.

For recurring operational failure, start with Root Cause Analysis. For business viability, connect the concept to Business Model Canvas.

Inputs required

• a bounded challenge and decision horizon;
• access to relevant people and situations;
• existing research, behavioural data and service evidence;
• explicit constraints: safety, regulation, technology, cost and time;
• a cross-functional team able to change the solution;
• a learning log for assumptions, evidence and decisions;
• materials or software for rapid prototypes.

Step-by-step process

1. Frame a provisional challenge

State the population, context and outcome. Treat this as a starting hypothesis, not the final problem statement.

Weak: “Design an AI scheduling assistant.”
Better: “Understand why clinic coordinators lose control of urgent schedule changes.”

2. Study people in context

Combine interviews with observation, artefact review and available behavioural data. Ask about recent events, not ideal future behaviour. Record what happened, what the person tried, what made the situation difficult and what success meant.

3. Synthesize evidence

Cluster observations without averaging away important differences. Separate:

• observed behaviour;
• participant interpretation;
• team inference;
• unresolved question.

4. Define a point of view

Write a claim that connects a specific person, an important need and an insight about the situation. Turn it into a design question:

How might we help clinic coordinators recover from urgent changes without losing confidence in the schedule?

5. Generate alternatives

Create options that differ in mechanism, not only appearance. Separate idea generation from evaluation. Include a “no new product” option and at least one service or process option.

6. Choose what to learn

For each promising option, identify the assumption that would make it fail. Prioritise assumptions by uncertainty and consequence.

7. Prototype the assumption

Use the cheapest representation that allows realistic behaviour: a paper flow, storyboard, role-play, clickable screen, concierge service or operational rehearsal.

8. Test and observe

Give participants a realistic goal. Avoid teaching them how the prototype is meant to work. Capture behaviour, comprehension, workarounds, trust and decision points.

9. Decide the next loop

Record what was supported, contradicted or left unknown. Choose to refine the concept, reframe the need, test another option or stop.

Visual model

Text alternative: contextual observation informs a problem frame, which informs alternatives and a prototype. Test evidence can return the team to any earlier mode or move a promising concept into viability and feasibility testing.

Interactive example

Scenario

PulseCare operates appointment booking for small clinics. Product analytics show that 28% of rescheduled appointments trigger at least one support contact. Managers propose a chatbot.

Research evidence:

1. Coordinators make urgent changes while speaking to a patient.
2. The screen confirms the new time but does not show which reminders will be replaced.
3. Coordinators keep handwritten notes until the patient confirms receipt.
4. Patients sometimes receive both the old and new reminder.

Your move

Write one point of view, one “How might we” question and a low-cost prototype that tests the most important assumption.

Worked answer

Point of view: A clinic coordinator handling an urgent change needs visible confirmation of every downstream update because the current success message does not establish that the old appointment state has disappeared.

Question: How might we make the consequences of a reschedule visible before the coordinator ends the patient call?

Prototype: a clickable confirmation panel showing the old reminder cancelled, the new reminder scheduled and the patient acknowledgement state. Test it with coordinators using three realistic reschedule scenarios.

This is stronger than prototyping a chatbot because it follows the observed trust problem rather than the manager’s preferred interface.

Facilitation notes

• Recruit people with recent experience of the target situation.
• Ask team members to write observations before discussing interpretations.
• Keep a visible distinction between evidence and inference.
• Invite operational, technical and policy constraints into ideation early enough to matter.
• During tests, assign one facilitator and one observer.
• End every session with a learning decision, not only a list of ideas.

Expected output

A sound application produces:

• a scoped challenge;
• research evidence and unresolved questions;
• a point of view and design question;
• several genuinely different concepts;
• an assumption map;
• one or more low-cost prototypes;
• test observations and decisions;
• a hand-off into technical, operational and business validation.

Common mistakes

1. Starting with a solution. Research becomes a search for confirmation.
2. Calling one workshop a process. Ideation without field evidence or testing is incomplete.
3. Treating stated preference as behaviour. People may describe an ideal that differs from what they do.
4. Building a polished prototype too early. Fidelity increases attachment and cost.
5. Testing by presentation. A positive reaction to a pitch is not evidence of usable behaviour.
6. Ignoring viability and feasibility. Human desirability alone does not create a sustainable solution.

Quality checklist

• The challenge names a person, context and outcome without prescribing a solution.
• Research includes behaviour or artefacts, not interviews alone.
• Observations, interpretations and assumptions are visibly separated.
• The team generated alternatives with different mechanisms.
• Every prototype tests a named assumption.
• Participants attempted realistic tasks without coaching.
• Evidence changed a decision, frame or next test.
• Promising concepts have a route to feasibility and viability review.

Template

Knowledge check

A team tests a polished app by explaining every feature and asking whether participants like it. What is the main weakness?

A. The prototype should always be built in production code.
B. The session measures reaction to an explanation rather than unassisted behaviour.
C. Design Thinking does not permit digital prototypes.
D. Participants should evaluate financial viability.

Answer: B. A useful test lets people attempt a realistic goal and reveals how they understand and use the concept without coaching.

Related tools

• Often combined with: Customer Journey Mapping, Jobs to Be Done
• Followed by: Business Model Canvas, experimentation and delivery planning
• Supports: service design, concept development and process redesign
• Not to be confused with: brainstorming, user-interface styling or product approval

References

1. Stanford d.school. “Design Thinking Bootleg.” Official resource (opens in a new tab). Source for the five-mode teaching model and iterative use.
2. IDEO.org. The Field Guide to Human-Centered Design. 2015. Official resource (opens in a new tab). Authoritative practitioner guide.
3. Brown, T. Change by Design. HarperBusiness, 2009. Practitioner account of design thinking in organisations.

Sources reviewed 28 July 2026.