Design Thinking - Part 3: Process - The Phase Model

René Andersen May 17, 2021

The design thinking series examines the complexities and concepts that comprise design thinking. In defining our approach to this way of problem solving and developing human-centred solutions, we hope to provide a clear understanding and ideas for practical applications. The following blog was created by our resident design thinking coach René Andersen. 

In the previous post, we explored the Double Diamond process model along with its two conceptual distinctions: the distinction between problem and solution, and the distinction between divergent and convergent ways of working.

These distinctions run at a fairly high level across the design thinking process. In the current post, we will drop down into a more fine grained view of that same process and examine the six HPI phases, which we introduced in the previous post.

You might recall “HPI” stands for “Hasso Plattner Institute” and refers to one of the world’s foremost design thinking centres of excellence, situated near Berlin in Germany. While it is not the only one out there, its six phased process model is one of the most widely used today and well worth understanding in detail. Mastering this model gives you a key to unlock all other design thinking process models you may encounter.

In this post, we will be guided by the same question that guided the previous post - just this time, we ask it at a more granular level:

  • What do you actually do when you do design thinking?

Let’s look at the picture once more that combines the Double Diamond and the HPI model. Note the six HPI phases, represented by colorful circles. We want to understand:

  • What do you do in each of these six phases?
  • What is the desired outcome of each phase?
  • How do these phases work together to create an end-to-end process?
  • Is this process linear?

The Six Design Thinking Phases

A first thing to note is how the six HPI phases are symmetrically dispersed across the problem and solution space: there are three of them in the problem space, and another three in the solution space.

As we will see, the phases elegantly link up in a logical way and form a sort of value stream that is getting richer and richer as a team moves through these phases from left to right and continuously adds value to it.

The value that the team adds to the stream is one of insight and pragmatism. It is insights into the world of users and stakeholders and their needs and problems. It is also insights into a range of possible solutions. Importantly, these insights are accompanied by at least one prototype, which is not only built but also tested. This is the pragmatism.


It is one of the hallmarks of design thinking that it is not content with gains of a merely intellectual nature. There is no satisfaction in even the most innovative ideas without testing them in the real world and letting the world decide to what extent they solve real problems.

The idealisation of linearity

As we will see more clearly in a moment, the output of one phase provides the input and starting point for the next phase. There is a tidy linearity to what we are about to cover - one phase follows after another in a linear fashion, there is a beginning and an end to the process.

It may be useful to keep in mind that this linearity is an idealisation. It is an idealisation in the precise sense in which the philosophy of science uses the term:


We will cover the topic of linearity in more detail in another post. For now, I invite you to simply note that:

  • linear design thinking processes do exist in the real world,
  • they have their place, and serve a purpose - they are often used to kick-off a new project or re-start a stalled one,
  • mastering them provides a great foundation for mastering more complex, non-linear scenarios.

With that in mind, let’s break down the HPI model and look at each of the six phases in turn.


The goal of Understand is for the team to gain an initial shared understanding of the problem space - and also to get to know oneself as a team that is more than the sum of its individual parts.

In this phase, as well as in all other phases, the design thinking team is typically supported by an experienced design thinking coach. This is particularly true if the team is inexperienced and / or has not previously worked together in this particular configuration, as can often be the case.

Typically, the team is not talking to users yet in this first phase of the process. Instead, it studies the design thinking challenge, which it has been tasked to tackle (e.g. by a project sponsor). It gathers and structures its own current thinking along with assumptions about users, stakeholders, needs, pain points, and anything that it deems relevant to the design thinking challenge at hand. In this first phase, the team warms up - in regards to both the subject matter of the challenge as well as to itself as a group of individuals trying to become a well-working team.

Remember (with a view to the Double Diamond), this is very much a divergent way of working: broad, associative, explorative, covering lots of ground, laying out anything that the team feels it should consider and discuss in order to tackle the challenge.

Specific methods that the team may apply in Understand include:

  • associative brainstorming (“What sorts of things come to mind when we consider this challenge? Who might the most important users and stakeholders be? What might their needs and pain points look like? What should we be aware of in tackling this challenge? … ”);
  • mind mapping (using the format of a mind map to visualise the team’s initial thinking);
  • stakeholder mapping (identifying stakeholders that are relevant);
  • system mapping (taking a system’s view of the problem space);
  • semantic analysis (examining the meaning of those words that are particularly
  • important to understanding the challenge);
  • user journey (mapping the journey a user might take, including the quality of their experience and any important touch points along the way);
  • charette (a table structure that explores potential users, potential needs, and any further topics the team may wish to examine).

At the end of Understand, the team will have an initial and broad-brushstroke understanding of the problem space - based merely on conversations amongst themselves. It provides the team with a base line and helps to highlight the assumptions it carries, which can be questioned once made explicit.

With a view to what is needed to get started in the second phase, the understanding gained in this first phase will include some thoughts on who the users are that the team will want to engage with in phase two, and some thoughts about what topics the team may wish to focus on during their interactions with users.


The goal of Observe is to develop genuine empathy for users and to leverage this empathy to gain valuable insights into who the users are as real people, and what the world feels like to them.

The focus for the design thinking team here is on uncovering people’s needs and pains. The team builds on the initial understanding gained in phase one, and deepens it through direct interaction with users. In phase one, the team talked about users. In this phase, it talks with users. It may also observe and / or shadow users in addition to speaking with them. It’s important to note:


It genuinely tries to get into the shoes of users and see the world with their eyes. Empathy is used as a powerful tool to gain deep insights into the problems that are real to real people. Afterall, the team is very much exploring the problem space in this phase. It fishes for problems that are worth solving in the context of the particular design thinking challenge that the team was tasked to tackle.

From a methodological point of view, common tools used in Observe include:

  • empathic, qualitative, semi-structured interviews;
  • observation or shadowing (quietly observing users in their natural habitat or workplace, without speaking with them);
  • a combination of observation and engagement (e.g. by asking someone to show how she does something)

At the end of Observe, the team will have (lots of) raw material gathered from its exploration of users and their needs and problems. This raw material may consist of quotations, observations and drawings documented on sticky notes or other pieces of paper, spread out and structured on walls or whiteboards. All of this can also be done in remote settings, e.g. through the use of such visual collaboration tools as Mural or Miro.

Point of View

The goal of Point of View is to analyse and synthesise the raw material gathered up to that point in the process and converge onto a refined, narrower framing of the problem to be solved.

The design thinking challenge that the team started with is usually large in scope. What the team aims to articulate by the end of Point of View is something more narrow and smaller in scope.

The team typically begins phase three by sharing all of the information that it has jointly accumulated and collaboratively reviewing it. Whereas in Observe, the team was still in a divergent way of working (collecting more and more information), in Point of View it switches to a convergent mode. It stops gathering more information, and instead digests, analyses, structures and synthesises what it has.

Some of the methods commonly used in this phase are:

  • storytelling (sharing the outcomes and insights from interviews, observations and shadowings);
  • nugget framing (identifying the most valuable pieces of information within a larger set);
  • personas (creating succinct and powerful representations of subsets of users);
  • user journeys (mapping the journey a user takes along an experience, including touchpoints and information on the quality of their experience at various points along the way);
  • point of view (using one of a number of pre-defined formulaic sentence structures to articulate a more narrowly defined subset of problems).

The end of Point of View is also the end of the first Diamond. At this stage, the team has gone through one cycle of first divergent and then convergent thinking.

Along the way, the team has moved from the broad and open design thinking challenge it started with at the beginning of phase one to a much more refined and narrow articulation of a subset of problems at the end of phase three. The team has also gained empathy and a direct understanding of who the people and stakeholders really are and what their real needs consist of.

Depending on the type of project and the more specific approach taken, the team may have also explored constraints, objectives and key results, missions and visions, values and purpose, and other parts of the context within which the particular design thinking challenge may be situated. None of these in themselves are specifically “design thinking” in nature. All of them can, however, be useful for a team to consider when applying design thinking in the real world.


The goal of Ideate is to generate at least one good idea that is likely to solve the problem(s) that the team articulated in the previous phase.

Ideate tends to be the most creative phase of the design thinking process, and there are many methods that can be used to increase the chances of a team ending up with really good ideas. These methods can be broadly divided into more introverted and more extraverted ones. More introverted methods tap into the potential of individuals who are strong when left to work quietly and by themselves. More extraverted methods will foster talking and exchange between team members and tap into the shared and social energy of a team.

There are a wide range of names that you might encounter as labels for specific ideation methods, here are just a few of them. As you explore them more closely, you’ll notice some overlap between them:

  • Brainstorming (everyone shares ideas out loud in a more or less unstructured way);
  • Brainwriting (everyone writes down their ideas instead of sharing them out load; one popular version of this is called “6-3-5” where in each of the rounds 6 people write down 3 ideas in 5 minutes);
  • Crazy 8 (everyone uses a grid of 8 boxes and creates 8 ideas in a short period of time);
  • Lightening Demos (everyone researches inspiring products or services and presents them to the rest of the team; this method is standardly used in so called Design Sprints);
  • Round Robin (people flesh out a number of ideas by moving from one idea to another and helping to gradually refine them and add further detail).

Typically, there are two parts to Ideate: first the team generates many ideas, including crazy ones. Then it analyses them, selects the most promising ones and refines these further.

At the end of Ideate, the team selects the idea(s) that it wants to prototype. These are the team’s “best shots” at solving the problem that it articulated at the end of Point of View.

With a view to the Double Diamond, Ideate begins as a divergent mode of working (generating lots of ideas) before it switches to a convergent mode (analysing and assessing ideas in order to select the best one(s)).


The goal of Prototype is to take the most promising idea(s) of the previous phase and turn them into something that can be tested with users to elicit useful feedback about the extent to which it solves their problems.

An idea that merely consists of a few words or scribbles on a sticky note can, of course, be shown to users. However, their feedback won’t be as rich and useful compared to being given something more tangible and detailed. At the end of the day, this is what a prototype is:


From an outputs perspective, the artefacts of this phase are distinctly different to those of all of the other phases. Instead of consisting of notes and drawings, prototypes come in many different shapes and forms, including:

  • role plays;
  • paper prototypes;
  • prototypes using a variety of small physical materials and craft tools, e.g. LEGO, playdough, colored paper, stickers, chopsticks, paper cups etc.;
  • detailed sketches;
  • process flows;
  • ecosystem maps;
  • digital click dummies;
  • life-size cardboard or plywood prototypes;
  • machines …

The type of prototype that a team will choose to use depends on a number of factors, including:

  • the type of challenge, and the type of solution (is the solution a process, a product, a service, a machine, a store front, an org chart … ?);
  • the availability of prototyping skills and tools (e.g. not every team has access to someone with professional UX / UI / design skills to quickly create effective digital prototypes);
  • time and cost.

At the end of Prototype, the team will have something that is much more pragmatic and immediately useful than the mere “ideas” that it had at the end of Ideate


The goal of Test is to let the world (the users) decide to what extent a prototyped idea solves their problems.

For each prototype, the team wants to find out what the users like about it, what they don’t like, what they don’t understand, and any ideas the users might have for improving the prototypes.

Depending on the type of prototype, there can be a range of different test methods, but a few general guidelines of testing apply no matter what the prototype:

  • Don’t fall in love with your prototype (this takes practice);
  • Remain as straight-faced as you can when you observe how users interact with the prototype of your favourite idea (otherwise you may interfere with the user feedback and lose out on valuable insights);
  • Do not sell your prototype (a common pitfall);
  • Remain humble and kind and present;
  • Focus on the learnings you gain, not the quick win you may lose;
  • Simply and succinctly explain what your prototype can do, the ways in which a user can interact with it - and then sit back, be quiet, observe, and take notes;
  • If the actual testing is finished before the end of the testing session (e.g. because it becomes clear within the first few minutes that your prototype completely and utterly fails to solve the user’s problems) then use Test phase as another shot at the Observe phase. Turn it into an empathic interview, dig deeper in your understanding of the user’s real needs. This can be incredibly valuable.

At the end of Test, the team will have an initial understanding about the extent to which their favourite ideas for solving someones problems do, indeed, solve their problems.

This understanding forms the point of convergence of the second Diamond. With the testing of the prototype the team has completed what could be called a full design thinking cycle: moving from a broadly defined challenge through a deep exploration of the problem space, a creative tackling of the solution space all the way to testing a potential solution in a most humble and pragmatic, outcome-focussed way.

Remember the value stream

We have now covered all six phases in some detail. Note, that the goal for each phase is well defined. The how, on the other hand, is not. Each of the six phases can be thought of as a container that holds a number of suitable tools and methods, each with their advantages and disadvantages.

Typically, every phase in a design thinking workshop is time boxed, and there is an overall expectation on design thinking to deliver great results in a short period of time. For each phase, there is freedom and responsibility to choose just those methods that will yield the best results for a particular team in a particular project context. An experienced coach will be able to guide the team in selecting and applying from the range of methods available for each phase such that the most value is added within the time box of that phase.

In reflecting on the process of design thinking, remember the analogy of a value stream. Starting with a design thinking challenge, the team moves through the six phases and as it does, it adds value to the stream by way of insights and - importantly - pragmatic outcomes in the form of prototypes that allow the world to give the team feedback on whether it has solved any problems yet.

We first seek to understand, discovering the right problem before the right solution. Then we create something we can test, because at the end of the day, doing is all that lasts.


René Andersen, Senior Product Owner and Design Thinking Coach at Trineo

Currently based in Christchurch, New Zealand, René has worked in digital transformation and innovation for more than thirteen years - across Germany, New Zealand and Australia. From large organisations to Start Ups, René enjoys combining methodological rigour with creativity and empathy, and is passionate about human-centered & iterative approaches to innovation and transformation. 

René Andersen

René Andersen