Proponents of design thinking want us to believe that design is a playful process that involves yellow post-its with ideas written on them, and kindergarten tools to make prototypes. This is a gross simplification of design. The design process may be tedious, may involve wicked trade-offs, and may involve math and software simulations to validate design choices. The hard part is not coming up with new ideas, but reducing the risk of selecting a design that will have unwanted and unforeseen consequences when implemented. In this blog I discuss the structure of design thinking. In the sequel I discuss how design risks can be managed.

The design cycle

From a logical point of view, design consists of three tasks:

  • Investigate the problem context. This is where you identify stakeholders who will use your solution.
  • Design possible solutions. Each design describes choices about hardware, software and organization that will be part of a possible solution.
  • Validate the solutions. This involves reasoning about the effects of each design in the problem context, doing experiments to test these effects, and assessing these effects on their contribution to stakeholder goals.

Contrast this with discussions, familiar to all of us, where someone just proclaims their solution to an issue without really understanding the problem nor willingness to test the solution.

I call these three tasks the design cycle, by which I mean that you can iterate over them until you found a satisfactory solution or time or money is up. There are many variations of this cycle proposed in the literature. The above one is based on an analysis of methods in product development and systems engineering in my book on design science and in an earlier book on requirements engineering. It is the simple core of design cycles in different disciplines.

To illustrate this, I compare my core design cycle with an industrial product design cycle from a book on product design, the IDEO design cycle and a cycle called DesignABetterBusiness. The green part of the table covers the core design cycle and the corresponding parts of the other cycles.

Design fun or design drudgery?

As you can see, the two cycles on the right use language that suggests fun, creativity and engagement. You find inspiration, ideate a solution, generate breakthrough ideas, bring your ideas to life, make them tangible, learn, gather feedback, and share your story.

By contrast, the two cycles on the left use language that suggest hard work, technical analysis and drudgery. You investigate the context, identify stakeholders, define criteria, survey existing solutions, generate new ones, simulate them, analyze sensitivity, do trade-off analysis, and compare your solution with those of others.

The two cycles the right use language common in design and consulting firms, the ones on the left use technical language. The cycles on the right refer to creativity and teamwork, the ones on the left refer to analytical tools and simulations.

These differences are superficial. As any technical designer can tell, technical design can be is fun, and involves creativity and teamwork. And as any business designer can tell, designing a business can be tedious, and involves analysis and simulation. Design processes differ in the tools used for analysis and simulation, but they can all be fun at times and tedious at other times.

But then what is the essence of design thinking? If they can all use empathy maps and paper-and-scissor prototypes, what sets apart design thinking from, say, day-to-day problem solving?

Tolerance of Uncertainty

The core of design thinking in all these approaches is tolerance of uncertainty. In a paper on the nature and nurture of design ability, Nigel Cross quotes the structural engineering designer Ted Happold:

“I really have, perhaps, one real talent: that is that I don’t mind at all living in the area of total uncertainty.”

Designers are uncertain about what the problem is, who the stakeholders are, what their goals are, what are the feasible solutions, what effects the solution will have when implemented, what the support for it is among stakeholders, how they will respond, and what the impact of their design will be. Designers realize they never completely understand the problem and will never completely know what the impact of their design will be.

There is no way out of this predicament. Spending too much time on analyzing the problem will make your solution outdated. Spending too much time on testing your solution does the same. There is always more to investigate and test and there is never enough time to do it. And making the wrong choice may lead to disaster.

How to manage this predicament? This is a matter for design management. I will talk about this in the second part of this blog.