Chat with Jurre

Blueprints

Design Thinking Canvas

The human-centred design process of the Stanford d.school in five workable stages.

The Design Thinking Canvas brings the five stages of human-centred innovation together on one page. It is made for teams designing new products, services or processes who want to avoid building without understanding the customer.

BoldcasterDesign Thinking Canvas · template

What is the Design Thinking Canvas?

Design Thinking is a design philosophy formulated in the 1980s by David Kelley and his colleagues at Stanford and the design firm IDEO. The idea: before you build anything, you need to understand the person you are making it for. The five stages (Empathise, Define, Ideate, Prototype, Test) are not a linear waterfall method but an iterative rhythm in which any step can send you back to an earlier one.

The problem Design Thinking solves: too many teams build solutions to problems nobody really has, or for customers who turn out to think differently than assumed. By organising empathy first (observing, listening, experiencing) you avoid developing a lovely idea that stalls in the wild. The canvas sums up the process so a team can see at a glance where it stands: are you still gathering, or can you start coming up with ideas?

Where Design Thinking falls short: it is a design method, not a business method. It says little about revenue models, channels, scalability or how to organise. Combine Design Thinking with a Lean Canvas or a Validation Canvas as soon as you have something concrete to test, and with OKRs or rocks once you start to scale.

When do you use it?

Reach for the Design Thinking Canvas when you face an open problem: 'we want to improve our customer experience', 'we can see our market changing', 'something new is needed, but we do not yet know what'. It works best in the divergent phase, before scope, requirements and deadlines lock the direction down.

Already have a hypothesis you want to test? Then use a Validation Canvas or an Experiment Canvas. Want to zoom in on the person before you step into the process? Build a Persona first and link it to a Jobs-to-be-Done analysis.

How to fill it in

Work through the five stages in order, but expect to go back a few times. Each stage opens with a question and closes with an artefact that feeds the next stage.

01

Empathise

In Empathise you gather insight without judgement. You observe customers in their own context, you hold open interviews, and you try out their work or life for yourself for a while. The aim is not to confirm what you already think but to be surprised by what you did not know. Good empathy produces quotes, photos, small stories and pain points you could never have made up beforehand, and they later form the basis of your problem statement.

Questions that help

  • ·What does the user actually do, as opposed to what they say?
  • ·Which emotions come up at each step?
  • ·Where does their behaviour differ from what they think they do?

Example

For a planning app: spending a week shadowing three construction firms, interviewing five job planners and asking an installer to plan their working week out loud while you watch.

Common mistake

Sending out an online survey and calling it 'empathy'. Questions you think up in advance force the answers into your frame.

02

Define

In Define you condense all the raw insights from Empathise into one sharp problem statement, often in the form 'How might we…?'. You state explicitly who you are solving the problem for, what their goal is, and which insight from the empathy stage makes the problem new. A good Define statement is concrete enough to build on and broad enough to leave room for creativity.

Questions that help

  • ·Who exactly has the problem, and in which situation?
  • ·Which insight from Empathise makes this problem different from what you thought?
  • ·Why is this the right problem to tackle now?

Example

How might we help job planners at SME construction firms finish their weekly schedule in 15 minutes, so they get home earlier in the evening?

Common mistake

Making the Define statement too narrow or too solution-oriented ('How might we build a planning app…'). That way you skip an entire divergent stage.

03

Ideate

In Ideate you generate widely, without judgement. Brainstorms, Crazy 8s, analogous inspiration, reversals: anything that helps you approach the problem statement from twenty angles. Divergence is followed by convergence: clustering, voting, choosing which three to five directions you want to explore. The biggest enemy of Ideate is the first good idea. Carrying on past the first 'that will do' direction almost always produces better solutions.

Questions that help

  • ·Which wild ideas break with the current approach?
  • ·Which ideas could we combine into something stronger?
  • ·Which three to five directions are most worth prototyping?

Example

In a two-hour ideation session, a construction team came up with 87 raw ideas. After clustering, four candidates remained: a drag-and-drop weekly calendar, a voice assistant, an automatic suggestions engine and a physical planning board with QR codes.

Common mistake

Stopping at the first 'nice' idea. The best ideas only come once you have worked through the obvious ones.

04

Prototype

In Prototype you build something cheap, quick and disposable that makes your chosen idea tangible. A paper sketch, a Figma flow, a role play with a colleague, a Wizard of Oz where the work is done by hand behind the scenes. The aim is learning, not making. The rougher the prototype, the easier it is for a user to criticise it; a polished demo invites polite nods.

Questions that help

  • ·What is the smallest thing we can make to experience the idea?
  • ·Which assumption do we want to test with this prototype?
  • ·How do we avoid investing too much time in something we are going to throw away?

Example

A paper version of the planning app, pasted into PowerPoint, with 12 screens clicked through by hand during a user session. Build time: four hours.

Common mistake

Building a 'prototype' that is really the working V1. You lose weeks and end up defending the feedback instead of soaking it up.

05

Test

In Test you put the prototype in front of real people from your target group. You watch what they do, you listen to what they say and, above all, you notice what surprises, annoys or confuses them. A good test does not check whether people 'like it' but whether they can complete the intended task and which assumptions about them turn out to be right. The outcomes feed back into Empathise, Define or Ideate; they almost never lead straight on.

Questions that help

  • ·What does the user do on their own, and where do they get stuck?
  • ·Which assumption from Define turns out to be untenable today?
  • ·What do we need to change before we test again?

Example

Five job planners tested the prototype. Three of the five did not understand the drag-and-drop when there were clashes; four valued the automatic suggestions engine.

Common mistake

Asking whether people find it 'nice' instead of whether they can complete the task. Aesthetic feedback is reassuring but says nothing about whether it works.

Common mistakes

Skipping Empathise and starting straight at Ideate

Brainstorming without understanding the customer produces ideas that fall back on assumptions. Invest at least half a week of real observation before you let anyone brainstorm.

Framing the Define step too narrowly or around a solution

'How might we build a chatbot…' is not a problem statement; it is already a solution. Keep the Define statement open enough for ten teams to come up with ten different directions.

Staying in one stage for too long

Design Thinking is iterative, not perfectionist. Keep to a time box for each stage and accept that you will go round more than once.

Making prototypes that look too finished

A polished prototype gets polite feedback. A rough prototype gets honest criticism. Deliberately build rougher than your instinct allows.

Interpreting test results instead of observing

First write down factually what people did and said. Only in a second round, preferably with the team, do you interpret what it means.

Treating Design Thinking as a project instead of a rhythm

A one-off sprint leaves little behind. Build it in as an ongoing part of product development, or the team will slip back into old habits.

In Boldcaster

How Boldcaster helps you with this

Fill it in interactively

No stray PDF lost in your downloads folder. Fill in the canvas in the app, with version history and comment threads.

Bold AI does the groundwork

Paste in your business plan, annual report or rough notes and Bold AI fills in the canvas for you. Or ask it for suggestions block by block.

Connected to your strategy

Send an insight from this Design Thinking to your Priorities, KPIs or strategy in one click, instead of leaving it on a whiteboard.

All canvases in one place

Pilot users get access to BMC, Lean Canvas, Value Proposition Canvas and whatever comes next. One platform, one system.

Prefer some guidance?

You don't need to know the models: Bold AI helps you block by block. Want someone alongside you to run the sessions with your leadership team? Start with the scale-up audit. After that, we're happy to introduce you to a coach from our network who works with Boldcaster.

Frequently asked questions

What is the difference between Design Thinking and Lean Startup?

+

Design Thinking focuses on understanding and design; Lean Startup on quickly validating a business idea in the market. In practice they complement each other: Design Thinking finds the right direction for a solution, and Lean Startup tests whether it works as a business.

How long does a Design Thinking cycle take?

+

A first full pass through the five stages for a single problem takes 2 to 6 weeks for a serious topic. Short design sprints in the Google Ventures style squeeze it into five working days, but deliver less depth.

Does Design Thinking work for B2B and complex organisations too?

+

Yes, especially there. It applies just as well in healthcare, financial services and industry as in consumer apps. The Empathise stage is a little more complicated because decision-makers and users are different people, but it works.

Do I need a designer to do Design Thinking?

+

It helps, but it is not required. What you mainly need is someone who dares to put observation above assumptions and who can guide people through divergence and convergence. Many teams train one team member for this.

How many people do you interview in Empathise?

+

For most B2B projects, 8 to 12 in-depth interviews are enough to see patterns. For broad consumer questions you often work with larger groups, but twelve good conversations beat fifty superficial ones.

Can you do Design Thinking remotely?

+

Yes, with tools such as Miro, FigJam or Mural. The Empathise stage remains the hardest to do remotely: video interviews work, but you miss observing people in context.

What if my team already has a solution in mind?

+

Write it on a note, put it in a drawer, and still go through Empathise and Define. If the same idea still rises to the top at the end, you know it holds up, and you also know why.

How do I measure whether Design Thinking delivers anything?

+

At process level: the number of hypotheses tested per quarter, and the amount of feature rework after launch. At outcome level: adoption, retention and NPS of what you made through the process. Compare with features that did not come out of the process.

What does a filled-in Design Thinking Canvas look like?

An empty canvas is the easy part. The hard part is what goes in it. I'll send you a completed Design Thinking Canvas: a fictional company, real wording, sharp enough to base decisions on.

See a completed example

The strategy canvas of a fictional installation company, fully completed. Plus five signs that a canvas actually steers the business, rather than just being filled in. Four pages, PDF.

You'll see the example straight away and get a copy by email. We keep your address so we can help with your strategy; unsubscribe any time in one click.