Skip to Main Content



Design thinking: what it is and how to use it to develop human-centered solutions

April 27, 2021By
People planning user experience design

This article 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.

Understanding design thinking

I like David Kelley’s quote:

"The main tenet of design thinking is empathy for the people you're trying to design for".

I also find it unfortunate that he used the verb “design” at the end of that sentence. It can give the impression that design thinking is all and only about designing things, rather than building things, or developing things, more generally speaking.

Fair enough of David Kelley to frame design thinking in terms of designing. After all, he was a Design graduate and later co-founded IDEO, one of the world’s leading design firms and one that historically helped make design thinking famous. However, I suspect he would also be the first to admit that design thinking is not just about designing (in the sense of the word that emphasizes the look and feel of something), and certainly not practiced just by designers (in the sense of someone who professionally practices industrial or visual design).

In fact, rarely have I seen such a delightfully diverse bunch of people as I have encountered among professional design thinking coaches. When I did my year-long design thinking coaching training at the Hasso Plattner Institute (HPI) in Europe there were people with backgrounds in business and management, computer science, sociology, engineering, political science, organizational development… you name it. There were also people with degrees in industrial and visual design, but only a few. And people came from a range of private as well as public organizations, bringing with them all sorts of problems that they applied design thinking to.

Empathy for the people whose problems you’re trying to solve

If I was to say something meaningful about design thinking, in line with the premise of David Kelley’s quote, it would be:

"A main tenet of design thinking is empathy for the people whose problems you're trying to solve."

Let’s break this down. First, although important, empathy is not the only tenet of design thinking. Second, by describing what is being done in terms of problem-solving, this opens design thinking up to a wide range of types of challenges you can usefully apply design thinking to: from software, engineering, product, and service problems all the way to social, societal, and political problems. People even apply design thinking to help solve personal life challenges in the areas of health, relationships, or finding meaningful work and purpose.

While design thinking started out as a study of “the way designers solve problems” (e.g. Nigel Cross “Designerly ways of knowing”, 1982; Peter Rowe “Design Thinking”, 1987), it has since evolved into a discipline of its own. Globally, the Stanford in the U.S. and the HPI in Europe are among the leading centres of excellence today, where design thinking is taught, researched, applied, and continually refined.

When I reflect on other approaches to problem-solving that I have come across in my life, it strikes me that design thinking is one of the most versatile things I have in my professional and private pantry. I avoid calling it a “method” or “tool” as I like to reserve these terms for something more granular than design thinking (e.g. a stakeholder map, a qualitative interview, paper prototyping …). Instead, I like to describe design thinking as an approach.

Mental models for the design thinking approach

I think of it as an approach to solve problems, or - if I want to be a bit more outcome focussed - as an approach to build products or services.

I like to call design thinking an approach because it is so multifaceted and complex. A few broad brushstroke characterizations might help to provide some initial context and to begin to see some of its contours:

  • It’s tightly structured at a high process level, and incredibly open at a granular tool level.
  • It‘s used by organizations around the world to develop innovative products and services, improve processes, and solve complex problems of any nature.
  • Its benefits revolve around efficiency (delivering good results faster), effectiveness (delivering great results), and organizational development (the process, when done well, is enjoyable and tends to leave the people involved in a happier and more productive state than they were before).
  • It‘s sometimes considered to be an agile method - and joined up with Scrum / Kanban, Lean Startup and the Business Model Canvas approaches.
  • It’s decidedly human-centered: it counsels to thoroughly understand the genuine needs of the people for whom you’re trying to solve a problem, build a product, develop a service, or improve a process.
  • It tends to focus on desirability (of a product, or service, or process …) more than it does on feasibility or viability. At least initially.
  • It recommends empathy as a powerful tool to unearth people’s real needs, and therefore, by proxy, as a tool to achieve great outcomes, such as delivering a product or service that precisely meets those needs.
  • It embraces failing early (being told by users that the first prototype sucks) as a means to learn faster and eventually deliver great results sooner.
  • It‘s usually a team sport (rather than performed by individuals working on their own) and under the guidance of a design thinking coach.
  • It tends to work best when the design thinking team is small (3-6 people), cross-functional, equal in the weight of their voices (no titles), and is allowed to work in a self-determined way.
  • It requires the team to be able to switch back and forth between wildly different modes of thinking and working: loosely associative and creative, rigorously analytical, deeply empathic, hands-on pragmatic, quick and superficial, slow and careful.
  • There is an emphasis on the mindset with which the team and the coach carry out design thinking. The mindset is focused on genuine respectful collaboration, wide openness, focus, mental and emotional flexibility, the ability to tolerate ambiguity, and an appetite for disciplined trial and error.
  • It works best when the problems are truly complex (not just complicated), when the team has direct access to users (and can interview and/or observe them), and when the team consists of true team players (rather than brilliant individuals).
    There is a thoroughbred, textbook version of it, which you encounter informal training, and then there is the art of making it work in real-world (client) projects that come with various (inconvenient) constraints.

Examining the key aspects to gain a deeper understanding

So what to make of all of this? I have only just begun to scratch the surface of this topic, and, for some of you, created more questions than I have answered.

To understand design thinking more deeply, it can be useful to divide its complexity and conquer its main aspects individually. In subsequent posts in this series, I will attempt to cover all of the following aspects of design thinking:

  • Process: What do you actually do when you do design thinking, and in what order?
  • Team: What is a good size for a design thinking team, who should be in it, and how should they work together?
  • Coach: What role does a design thinking coach play?
  • Mindset: What characterizes the mindset with which design thinking is practiced?
  • Workspace: What are the key requirements for a physical space that will support rather than hinder design thinking? And how can design thinking be done remotely?
  • Workshop: How do you structure design thinking workshops, and how do you facilitate them well?
  • Scaling: How can you scale design thinking to make it work in small as well as large projects?
  • Adaptability: How can you adapt design thinking to real-world client projects that come with constraints that the textbook design thinking scenarios don’t include?

The design thinking process

The above information touched on process, team, coach, and mindset. Now we're going to dive deeper to answer the question, what do you actually do when you do design thinking?

Let’s begin with pictures you may find when you go looking for “the design thinking process”.

Design thinking process diagrams

These are examples of ways in which design thinking processes have been visualized. This selection is not conclusive, and organizations tend to keep creating their own versions as we speak (SAP and IBM are shown above as two such examples).

When I worked as part of an internal innovation team at Transport for New South Wales (Ministry of Transport) in Sydney back in 2016, we did the same thing - we took some basic building blocks of the design thinking process and wove them together with some of the processes and concepts that were used at the Ministry at the time.

This can be a useful exercise as it forces you to think about how components of design thinking harmonize (or fail to harmonize) with the unique, pre-existing reality of your organization. If successful, this exploration will result in an integrated and enriched view of the way things are done in your organization. It will also highlight opportunities for improvement or refinement because design thinking tends to put things on the map that many organizations aspire to (e.g. working in ways that are genuinely collaborative, innovative, efficient, and fun).

Let‘s have another look at the picture of the different process models. While their differences may be confusing at first, a closer look reveals that:

  • some models are more widely known and used than others, and
  • underneath the differences are significant similarities.

In view of the first point, it’s probably fair to say that the three models in the top row are among the most widely used today and tend to be the ones shown in formal design thinking training. If you understand these three models you will have a good compass for navigating the rest of the design thinking process jungle.

D.School, the HPI model, and the Double Diamond

I was trained in the so-called HPI model. HPI stands for “Hasso Plattner Institute”. Hasso Plattner is one of the founders of SAP. He’s also a billionaire and philanthropist. In that capacity, he founded the design thinking institute known as the “” at Stanford University in the U.S., and he also founded the sister institute known as the “HPI”, which is located near Berlin in Germany.

The HPI in Germany and the in the U.S. are design thinking centres of excellence to this day. The corresponding process models are very similar. The HPI model has 6 phases, the model has 5, but the last three phases are identical.

Also famous is the so-called Double Diamond model by the British Design Council, pictured as the third model in the top row.

The Double Diamond is often combined with the HPI and models. The first diagram in the second row shows one such common juxtaposition. It is this diagram that I personally find the most useful of aIl models, and it is this one that I like to use for our initial examination of the design thinking process.

A good understanding of this diagram provides you with a key to unlock and understand any design thinking process diagram that anybody may put in front of you, including the so-called “Design Sprint” (which has become popular in recent years), the IDEO diagram, and the “Fuzzy Process” diagram (all included in the picture above).

The HPI & Double Diamond process model

Let’s take another, closer look at this picture then, which combines the Double Diamond and the six HPI phases. The Double Diamond represents a coarser level of granularity. We will start with that and become more fine-grained in our examination once we‘ve understood the process from the high-level Double Diamond perspective.

Double diamond perspective diagram

Double Diamond

The Double Diamond are the two grey shapes in the background. They are labeled “Problem space” and “Solution space”.

Design thinking is very disciplined about distinguishing the problem from the solution. It advises not to think about solutions until you’ve gained a good-enough understanding of the problems. This advice is based on the experience that if you lift your empathic gaze off the people in front of you (with their often complex and conflicting needs) and start to think about solutions too early, then you can end up solving the wrong problem. The first diamond is all about research. You study the people, you study their needs, their behaviors, their workarounds, their unsolved problems.

It often comes as a surprise to people new to design thinking that about half of the available time in an initial design thinking workshop is spent exploring and understanding the problem space. Only after spending sufficient time with the people whose problems you are trying to solve do you move on to start exploring potential solutions. The fact that the two diamonds are equal in size is a visual representation of this recommendation.

If the first diamond is about solving the right problem, the second diamond is about building the right solution. The process of the second diamond comprises ideation, prototyping, and testing. Here, you try to quickly and cheaply build something that looks like it might solve the problems. Then you test it to find out whether it does or does not. You note what people like about your proposed solution, what they don’t like, what they don’t understand about it, and any ideas they might have about how to improve it.

This is where you get to at the end of the second diamond: an initial, validated prototype. Something that tangibly represents an idea for a solution, and because of its tangibility allows you to effectively test it with real people and get some real feedback.

The divergent mode of working

While the number of diamonds (two) is significant, their shape is also. The diamond shape is intended to visualize two very different modes of thinking and working: divergent and convergent.

You always begin a design thinking process in a divergent mode of working: you open up wide to take in a broad spectrum of information, you think in loose associations and generate lots of points of reference. A design thinking team in this initial phase of the process could, for example, create a mind map of all the stakeholders, users, and user problems it can think of, and of any topics that the team thinks might be relevant to the project. In a next step, the team might go out and interview a number of potential users and stakeholders and thereby generate further material. This would still be part of the divergent mode of working, which generates an increasing amount of raw material.

The convergent mode of working

At some point, however, the team will switch to a convergent mode of working. After having completed an initial set of user interviews, the team will typically shut the flood gates to any additional information and switch to analyzing all of the information gathered so far. This might involve clustering information by topics, finding patterns, identifying duplicates, condensing insights, and generally converging to a more narrowly defined articulation of a problem worth solving.

You see, typically the task that a design thinking team starts with at the beginning of a design thinking process is quite broad. In design thinking jargon, it is called a design thinking challenge and is deliberately formulated in a rather open way that invites further exploration of who the people (users) are, and what their needs and pain points consist of.

The end of the first diamond marks the end of the exploration of the problem space. At this point in the process, the design thinking team should have gained a good understanding of who the users are and what their key unmet needs and pain points look like.

Often, there are many different users with many different needs and pain points. There are lots of problems to be solved. Because design thinking workshops are typically time-boxed, and a design thinking team can only achieve so much in a given time frame, this is the point in the process where the design thinking team decides which subset, or part of the problem, it wants to solve in the current workshop (keeping in mind that it may have a chance to tackle other subsets in subsequent workshops as it starts to iterate - we’ll cover this later).

For example, if the initial design thinking challenge was “Improve our workplace” (very broad), then at the end of the first diamond, the team might have converged to a problem definition like “Improve the efficiency of our onboarding process” (much narrower).

Divergence - convergence. Repeat.

The team now enters the second diamond and goes through the alternating divergent - convergent rhythm once more. Just like it did at the beginning of the first diamond, it begins the second diamond by working in a divergent manner: it stretches its imagination wide and generates lots of ideas, including far-out, crazy ones. At some point, it stops generating ideas and switches to a convergent mode of working. It analyses the ideas and selects one or two, which it assesses as being the most promising ones to solve the problem it had articulated at the end of the first diamond.

Next, the team prototypes the selected ideas. This means it will quickly and cheaply create something that it can test with users. In a software project, this may be a paper prototype, or a few sketches.

The final part of the second diamond consists of the testing of the prototype. This results in the second and final point of convergence: the feedback that users give about the prototype. With that, the Double Diamond has been completed.

In summary, the process symbolism of the Double Diamond is twofold. It counsels to:

  • distinguish problem from solution, and spend sufficient time exploring the former before starting to think about the latter;
  • systematically oscillate between divergent and convergent modes of thinking as a way to efficiently and effectively work your way through a design thinking cycle.

From the Double Diamond on to the six HPI phases

Now that we have covered the topic of process from the high-level perspective of the Double Diamond model, we are ready to deep dive into the more fine-grained HPI model that splits a design thinking cycle into six distinct phases. This is what I would like to explore in a subsequent blog post. As we will see, the six phases map neatly and symmetrically on to the Double Diamond: the first three phases are located in the first diamond, the latter three phases in the second diamond.

Exploring these six phases will provide us with a more fine-grained understanding of the design thinking process and give us the opportunity to delve more deeply into some of its more well-known components, such as empathic user interviews, how-might-we questions, creative ideation, pragmatic prototyping, and straight-faced testing.

The Double Diamond process model has 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, so now let's get into a more detailed view of that same process and examine the six HPI phases.

The Phase Model

Let's think about the phases outlined in the Double Diamond and HPI model.

Design thinking process

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.

Borrowing from Kant, we could say: insights without prototypes are empty, prototypes without insights are blind.

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 idealization 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 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 idealization. It is an idealization in the precise sense in which the philosophy of science uses the term:

The linearity of a design thinking process assumes facts about the phenomenon being modelled that are strictly false but makes this model easier to understand.

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 visualize 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 understand the challenge);
  • user journey (mapping the journey a user might take, including the quality of their experience and any important touchpoints 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 baseline 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:

Whatever the team does, it does with empathy.

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. After all, 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 analyze and synthesize 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 synthesizes 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 extroverted 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);
  • Lightning 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 (analyzing 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:

A prototype is something more tangible and detailed than a few words or scribbles on a sticky note.

From an outputs perspective, the artifacts of this phase are distinctly different from 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 storefront, 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 favorite 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 of the extent to which their favorite ideas for solving someone's 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-focused 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 its 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.

Human-centered solutions start here.

Let's chat about your customers and design an unmatched experience for them.

Related Articles