Design Thinking made actionable

For quite some time Design Thinking has been hailed as a silver bullet for managing innovation. As a design agency, we’ve been sold on the process for a while, albeit we felt existing visual representations were not self-explanatory enough to get one started with the process. When it comes to illustrating (the) Design (Thinking) process(es), most of what can be found over the Internet looks like this:

Although these might serve as a general reminder to people familiar with what comes into play at each stage of the methodology, they won’t get a beginner anywhere: they aren’t descriptive enough to help guide a design process on their own. What is one to do with “empathize” or “define” as instructions? If this was to serve as a roadmap, what would be one’s first move? How should they know when they’d gotten to the bottom of things? Agreeably this is not what these were made for. Yet, what if a visual representation of the method also explained how to apply it to concrete cases?

As said, we have been using Design Thinking for some time now, we adapted it into a framework that works for us and is clear enough in our heads. Realising how much clarity we’d gain in conversations by laying it out visually made us want to put pen to paper. The goal was to represent our process into a highly actionnable and autonomous map, allowing one to visualise the different steps in a single frame and navigate them back and forth without (much) external help nor further knowledge. Here is what it looks like:

For further clarity we have taken each element apart and explained it here.

Starting point:

In our view there can be only two starting points to solving a problem:

1. Look into a target market to find out what people are struggling with. Before we go about looking into the market, we verbalise our initial assumption of the struggle in the following way, serving as a starting point (input) to be verified while making further exploration:

2. The second approach is to start with a product / problem perspective: “I have a product / service idea and want to assess how it can answer current problems and be better than competing solutions.” Similarly to the customer hypothesis we start by verbalising our assumption for what may become a game changer, next steps help validate or contradict this initial statement.

Similarly to the customer hypothesis for the market* driven activities, the value hypothesis serves as a fire starter to the product* driven activities.

A word about terminology:

“Value”: can sound esoteric to some. In a nutshell it’s another word for the product or service an organisation is building to derive money (or any other benefit) from. Or to put it into other words: “why” people should be interested.

“Hypothesis”: we talk about hypotheses because until proven valid, everything we come up with in the design process is an assumption about the market and our product. All assumptions are verified in the testing phase.

*Market can be replaced by “user” in case we’re building some non for-profit innovation.

*Product serves as a generic term for the sake of explanations and can be replaced by “service” when relevant.

Reading the table

The rest of the model reads as a pivot table: if we want to know what input is required to start market research activities we simply need to look into the corresponding box. Same goes for all the phases, inputs, methods, tools and outputs within the table.

Table Components

Phases (or entrance points):

A team working on an innovation initiative can enter the process by any of the four phases, provided that the required inputs for each phase have been gathered and agreed upon by the team. We trimmed down the six usual phases described in traditional Design Thinking processes to four:

1. Research: Knowing who’s struggling with what and who’s offering some kind of alternative is where it all begins. No user-centred design process can happen without an in-dept knowledge of the user and his surrounding environment. When done thoroughly the output of this phase is a good grasp on the user struggles: by the end of the research activity we should have gained a better perspective on the context: potential gaps between the current situation and a better outcome.
2. Ideation: Having gained an in-depth understanding of the situation, we can start generating ideas and thinking of how to come up with a better solution to the current user struggles.
3. Creation: Time to bring our ideas to life: prototyping tools are our arsenal of choice at this stage. Even when the final product is a tangible physical product it can be time and cost saving at an early stage to use digital tools to prototype a fake website or promo advertising the benefits of the product in question and see how potential users react instead of building the full product itself (see Wizard of Oz prototype for more info on that).
4. Testing: It’s showtime: time to recruit some real potential users, see how they do with our product or service and get potential validation of our initial value hypotheses.

Questions to answer:

Methodically connecting each phase to the next removes ambiguity as much as possible and allows team members to understand the basis for each assumption and to circle back to the appropriate phase if /when necessary. Clear research questions at the beginning of each phase clarify what needs to be done and avoid misalignment between team members.

Inputs:

Every phase starts with one or more “inputs” (i.e. artefacts, questions, data points). Inputs from a given phase are the outputs generated from at least one prior phase. As an example, the ideation phase requires three inputs derived from prior phases:

1. Initial customer hypothesis or market problem / question (aka what we’re trying to figure out)
2. Problem scenario(s) (the thing people are struggling with)
3. Persona description (the people that are struggling with this problem)

Only by having clarity on these three points can we have a useful ideation session, if clarity is lacking one should go back to the phases that will yield these inputs.

Methods:

Methods are techniques one can apply at each phase in order to discover information that will help solve the initial question being asked. For readability purposes not all methods and tools could be fitted in the boxes. We listed those we deemed the most actionnable. More methods and further explanations will be provided in follow-up blog posts.

Tools:

Every method is supported by a set of tools. A “tool” can be anything from a printed interview guide to recording software for running usability tests.

Outputs:

Outputs are the results (insights) that each phase should yield as a result of applying the methods. The output of a given phase serves as an input to the next phase. If the output lacks clarity, for instance is not measurable and/or falsifiable, one should revisit any prior phase to try and understand where clarity was lost.

Market ideation & creation exception:

Those two areas of the canvas are greyed out to reflect that one doesn’t ideate nor creates a market out of thin air. A new market emerges as a response to creating an innovative product or service answering unexpressed needs.

Final thoughts:

The main constraint we set ourselves to come up with the canvas was to make it fit a single A4 page to facilitate printing and its use by teams working on innovation projects. By no means is it meant as an exhaustive representation of Human Centred Design discipline, techniques and tools. Our idea putting it out there is to help individuals and teams structure thoughts around their innovation process through a series of defined steps and questions to answer.

Obviously we are believers in iterating and improving, hence the canvas is made available under a Creative Commons licence allowing anyone to make usage of the it, provided you make attribution to the author and share your versions under the same licence we did.

If you require a printable version of the canvas, PM me and I’ll be glad to send you one.