Re-thinking design thinking part II: What is wrong with the design thinking process

In the first part of this blog post series I introduced the current dominant design process and claimed how it is time to renew it. Now let’s dig a bit deeper in what I think is not quite right with it.

What is a process?

Let’s start with the basics. A process consists of tasks that take an input and give out an output that is then further given as input to the next phase. For the project at hand, you select the appropriate methods for each task, so that the tasks appropriately process the input and turn it into the output with the given resources and accuracy. A project is finished when you have gone through the tasks in the process and created the expected output of the last task.

No inputs, no outputs

The first suspicious thing about design thinking process is that it has no specific inputs or outputs. Each phase or task in the process is described as an activity (e.g. research) but it is very vague in terms of inputs and outputs. How can we define a task within the process if we have no requirements for the inputs for the task? How do we know if a task is successful and that we can move on to the next phase if we have no idea of what the outputs should be?

No support for method selection

Design thinking and HCD descriptions typically list tens, if not in total hundreds of different methods that we can use in each phase. However, there are not really proper criteria to choose among the methods. How could there be, if we are not clear what results we should be expecting from each phase? It seems that the methods are mostly chosen by two factors: the methods that we have the resources and time for, and intuition.

I’m not making a claim that the method selection by these two criteria would be wrong. On the contrary, competent designers by their experience most probably can select very appropriate methods for each task. Sometimes for a quick study, a few qualitative interviews will be enough, and sometimes a thorough contextual observational study will be required. The process model, however, is just a list of things to be done, but has very little guidance on what the outcomes should be, and therefore has no guidance about which methods would be appropriate, and when you are ready with a task.

Iteration on the wrong scale

The standard order in design thinking or HCD process descriptions is: analyse — define — ideate — prototype — evaluate. There will always be a small remark that you should iterate when needed. Some process charts have arbitrary arrows going from one phase backwards to an earlier one (see e.g. “Five stages in the Design Thinking process” at interaction-design.org— can you explain the arrows?).

If you are familiar with the contemporary agile design processes, you know that the iteration takes place weekly, whereas design thinking process is implying that the iterations are of a magnitude longer in nature. If in evaluation phase you conclude that you must iterate back to research phase, it sounds like you need to start the project almost from the scratch. In reality, this will never happen — you can’t afford it.

The iteration in such a large scale as visualized in the high level process descriptions are far from realistic. This kind of process model for iteration will not be of much use in the daily life.

Unrealistic order of the process phases

The order of the phases is unrealistic, and it will impose rigid order. Yes, there always is “iteration” and dotted lines pointing backwards to previous phases. But if at any phase there’s an option to go back to previous phases whenever need be, what is the point of the order in the linear phased process visualization? If iteration to any previous phase is possible at any point, will that not render the initial ordering of the phases practically useless?

Strict interpretation of the phases will also create inefficiency. If at some point there are good ideas that would need iteration back to earlier phases, it may mean that first one phase needs to be finished, then the process re-starts from an earlier phase with new inputs. For example, if during the prototyping and evaluation phase we notice that our assumption of the target group was false after all, we need to either ignore the finding or redo all the previous phases.

If you have worked with agile software development and tried to align HCD to that, you know that by nature they are not compatible. Agile has frequent iterations, sometimes as fast as one week each. Design thinking process describes only major iterations back to earlier phases. Naturally, you can argue that also in design thinking process you can iterate as frequently as you like, but this is in no way supported by the visualization of the process.

Most importantly, a semi-linear process is not suitable for wicked problems. When we squeeze a wicked problem through the HCD process, where we define the problem early, we tame the problem into too simplistic design tasks.

False manageability

The linear representation of the process gives us a feeling that we can in a straightforward project management manner set dates to the phases and assign a suitable amount of resources for each phase. This is naturally good when we sell a project using the HCD process within the organization: it looks manageable and relatively straightforward, because it provides set results with a fixed budget that you can track on the way. In reality, it’s far from it.

Agile software development has since long abandoned the idea that there is a managed and controlled process that can produce promised results in the defined time frame and within defined resources. Instead, they allocate resources and create a plan to implement the required features (epics and use cases) in the order of descending importance, until the project runs out of resources and time. HCD needs to do the same. Design is not a waterfall that will at the end spit out the solution as planned. We must be like agile: design with increasing accuracy until we run out of resources or time.

If you are interested in digging deeper in the agile, please go to the original source and read the original article by Takeuchi and Nonaka. The principles presented there are highly relevant for designers as well.

The problem of a problem that is not a problem

If you haven’t so far read the seminal article by Horst Rittel: “Dilemmas in General Theory of Planning,” from 1973, you definitely should. Although it was written 45 years ago, it is still fresh as ever. That is the original article that introduced the idea of “wicked problems”.

Practically all design problems are wicked. The design thinking process is often described to start with a “problem”. However, Rittel argues that it is actually impossible to articulate the problem without stating at the same time a proposed solution. This thought is quite disturbing if you are used to thinking of problem solving as a linear process.

“The information needed to understand the problem depends upon one’s idea of solving it. That is to say: in order to describe a wicked-problem in sufficient detail, one has to develop an exhaustive inventory of all conceivable solutions ahead of time.” — H.Rittel

I’m sure you are familiar with the difficulty of defining the starting point of the project. Sometimes the starting point is not a problem at all; it can be an identified opportunity, an attempt of making something enjoyable even better, a hunch that we could find something interesting in a focus area, it could be an idea for a service, or a product that needs a refresh. Very few of those starting points for design could actually be called “problems”. It would be very difficult to try to formulate them as one.

The problem of the solution that is not the solution

When you are done with the design thinking process, the end result is “the solution”. That is also somewhat loaded word. The solution sounds like an artefact that is intended for solving a problem — which itself was quite ill-defined term. Many times a designed artefact is only very small part of the end results of a design process. Equally important are the increased understanding of the topic, different practices and needs of the people and companies involved, the future plans and roadmaps, the open questions to be looked at later, and the hypotheses of what will happen when the solution is introduced.

The real impact of the results will be understood only in the long term. You will encounter both expected consequences, but certainly also many unexpected ones. The “solution” that you created may actually not solve the original problem at all.

“For wicked planning problems, there are no true or false answers. “ — H.Rittel

The bad news is that this part of the process you cannot iterate. You can’t rewind the time and start the design all over again. When you introduce your artefacts into the wild, it will affect the set-up so that the starting point of the design is no more the same. You must always proceed; you can’t go back.

The story about the industrial designers

I used to work at Nokia with brilliant industrial designers who created the dominant form factors of mobile phones and thereby shaped the lives of the whole humankind. I got to observe very closely the process that designers with an education and background in applied arts use.

A typical design session with industrial designers starts with a very loose target setting, for example ideating forms and shapes for a camcorder integrated within a mobile phone. Designers spread out to individual or small group work to sketch wildly lots of different ideas. After a sketching session they have a critique: they analyse the sketches and identify the positive aspects among them: “This is really good because of X”, “This is interesting, because of Y”, or “This will work well for people that are Z”.

For me, trained as an analytical UX practitioner, this was outrageous. There was no a priori analysis of the needs of the target group, nor a good definition of the problem to be solved, or any definite criteria to evaluate the ideas against.

Then it dawned to me. This is not a question of better or worse. This is just different. These designers actually were identifying the criteria for good solutions, but just in different order. They listed quickly the qualities X, Y, and target group Z, that were of course not yet validated in any way, but they already had a hypothesis of potential criteria that could be validated later. They had not been constrained by the set criteria beforehand so they were free to explore within the domain. In addition, they already had some design proposals that will respond well to those criteria, if they are proven relevant. I simply couldn’t claim that this generative process would be any worse than my analytical one. But theirs was so much faster than my process that would have required a month or two analysis and definition phase. This insight made me think if the text book HCD process were the best one after all.

Stay tuned

We have now identified fundamental problems in the current dominant design process. It uses visualizations and vocabulary that limit how we think of design. One of the first things we need to do is to free our minds: forget the current words and established process models for a while. We must look further, not just on our own field, to break out from the restrictions. This will be the topic for the next blog post.

(To continue the journey, proceed to Re-thinking design thinking part III: Ingredients of the new design process)

References

1. Dilemmas in General Theory of Planning. Horst Rittel, Melvin Webber, 1973
2. The New New Product Development Game, Nonaka & Takeuchi,1986
3. Design isn’t a Shape and It Hasn’t Got A Centre: Thinking BIG About Excellences in Post-Centric Interaction Design, Gilbert Cockton, 2013
4. New Process, New Vocabulary: Axiofact = A_tefact + Memoranda , Gilbert Cockton, 2017

Panu Korhonen is a designer at Nordkapp who sometimes wonders why things are done the way they are done.

In his projects he wants to create designs that save the world.