‘Design thinking’ is being touted from the classrooms of Ivy-league business schools and the stages of innovation conferences as a new methodology for attacking ‘wicked problems’. Design thinking, as Gartner analyst Nicholas Gall puts it, is a ‘major business trend that is driving fundamentally new approaches to enterprise transformation’. Gartner’s particular brand of design thinking (‘hybrid thinking’) allows business leaders to ‘create successful outcomes to wicked problems by co-creating more meaningful, human-centred experiences’.
Being able to consistently create successful outcomes to wicked problems is big claim. Neither Tim Brown’s ‘design thinking’ nor Gartner’s ‘hybrid thinking’ have published definitive methods or even answers to how you might go about the task. But it is true that increasingly, the traditional tools of systems analysis are looking dated and brittle in the face of business complexity and change. It could be argued that as technology routinely automates many of yesterday’s problems, today’s problems get tougher.
So-called ‘wicked’ problems are often sociological in nature, being of global or societal scale, involving large numbers of actors with divergent views and motivations. The undisputed czars of sociological problems are Horst Rittell and Melvin M. Webber, who coined the term ‘wicked’ in 1967, long before American teenagers appropriated it as a synonym for cool. A ‘wicked problem’ is a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. Moreover, because of complex interdependencies, the effort to solve one aspect of a wicked problem may reveal or create other problems. Some other characteristics of wicked problems include:
- The problem is not understood until after the formulation of a solution
- The problem has no stopping rule
- Solutions to wicked problems are not right or wrong
- Every wicked problem is essentially novel and unique
- A solution to a wicked problem is not usually repeatable
- A wicked problem has no alternative solutions.
Classic examples of wicked problems include long-standing economic, environmental, and political problems. A problem whose solution requires a great number of people to change their mindsets and behaviour is likely to be a wicked problem. There are many examples of wicked problems in public planning and policy, including global climate change, depletion of natural resources (forest-stripping, over-fishing), healthcare, managing epidemics, drug trafficking, security, nuclear weapons and waste. In arguing that ‘the search for scientific bases for confronting problems of social policy is bound to fail because of the nature of these problems’, Rittell and Weber drew attention to the broad objectives of the new social sciences in the late 1960s. Because all design effort addresses some kind of problem, it’s worth thinking about how problems are framed and understood by designers.
All design commences with an understanding of a problem, and all design methods must address problem definition as a starting point. Definition of a problem is locked in time—a solution is called for because a problem exists now. But problems and solutions exist in a kind of continuum. Sometimes, looking at the history of a problem re-casts it as resulting from previous efforts to solve past problems. Put simply, today’s problems are yesterday’s solutions, and today’s solutions are destined to become tomorrow’s problems.
In the mid-nineteen seventies, computer programmers working in assembly language were faced with small memories on their computing machines. They solved the problem by making efficiency their mantra, minimising the amount of ‘core’ used to store transaction fields such as dates by storing only the significant digits of a date. The solution became idiomatic and was applied well past the point in time of its origin and need, even in languages such as ForTran and COBOL. Twenty-five years later, the storage problem’s solution of the sixties had become the biggest and most expensive problem in the history of computers—Y2K. The 2-digit date problem represents a change in temporal scope—never in their wildest dreams had the programmers of the 60’s expected their software to still be executing three decades later. In the same period, Moore’s law had demolished the need for efficient date storage.
Domestic architecture illustrates this point graphically. Every walled-in porch, extension through the roof and out into the backyard evidences the gradual transition of societal expectations of acceptable housing, as successive generations start to perceive the previous generation’s comfortable solution as a constraining and intolerable problem. Recognising this continuum of problems and solutions affords a more informed view. At any point in time, the configuration of a house, an airframe, an industrial machine or a software product architecture is at once a problem and a solution, depending on where you stand.
Another problem with problems is that of knowing when the problem has been adequately defined. Design problems are full of uncertainties, both about the goals of the design effort and their relative priorities. Most of the time, the software designer cannot be sure that all relevant aspects of the problem have been discovered. This makes the boundaries between problem specification, analysis, design and coding fuzzy, and accounts for a major motivation for iterative software development lifecycles. Design theorists recognised this a long time ago. Back in the late 1980’s Egon Schirmbeck and Robert Venturi were amongst the first to challenge the established notion that design was a discrete stage in a sequence from product conception, through design and manufacture to product delivery. They recognised that the design process could change a project’s goals:
To avoid misunderstanding, it should be mentioned that there is no logical sequence of steps in design. Revisions of the goals made in the beginning ultimately determine the design process. Venturi even considers it legitimate to define the ultimate goal of a design only after one has backtracked to it during a modification (Schirmbeck 1987, p.2).
Problem definition and solution design are in constant tension. The process of designing uncovers and emits new problem elements which can subsequently change, extend or even invalidate elements of the solution already designed. Problem definition needs to be viewed as being in dynamic tension with solution definition. Problem definition invites opening up questions of objectives, goals, scope and function, whereas solution definition attempts to freeze these negotiable elements in time and space.
There are still other ways that problem definition is problematic. Problems are not always black-and-white. Many problem characteristics are subjective and require a degree of interpretation. Different designers or stakeholders in the design process typically interpret problems or problem characteristics differently. Bryan Lawson, author of How Designers Think, gives an example of subjective interpretation. The particular problem involves a passenger train service that is losing money and is destined for closure unless something is done. An industrial designer proposes a solution involving the redesign of a buffet car, drawing on their transport and vehicle design skills. An operations researcher designs a solution involving a re-scheduled timetable, based on information collected about the current users of the service and the travel demographics of the regions serviced by the train. A graphic designer proposes a solution based on modernising the internal decor of the train and redeveloping the menu and bar service within the buffet car. All solutions address an aspect of the problem, all are feasible and implementable, and all make a difference. So which one is right?
There is no objective or logical way of determining the right scope for a given problem; indeed, there are many possible scopes to be chosen from. The decision is typically made largely on pragmatic (i.e. economic) grounds—power, influence, time and resources. Today’s designers need to understand the importance of taking a systemic view of the part of the problem made visible in the design brief. In particular, an experienced designer must trace the processes and systems implied or discovered within the scope of the brief or problem description to their end-points, to ensure they are fully understood. Similarly, designers must ensure their solution does not invalidate a behaviour or assumption of the enclosing systems. Where problems are concerned, context is everything.
The best place to find guidance on how to recognise problems as manifestations of the behaviour of systems is Peter Senge’s ‘Fifth Discipline’, which spurred the Systems Thinking movement. As for methods that claim to reliably ‘create successful outcomes to wicked problems’, well, they don’t and probably never will exist.
Schirmbeck, Egon. (1987), ‘Idea, form, and architecture: Design principles in contemporary architecture’, Van Nostrand Reinhold (New York).
Senge, Peter M. (1990), The Fifth Discipline, Doubleday/Currency.
Rittel, Horst, and Melvin Webber.
Dilemmas in a General Theory of Planning, pp. 155–169, Policy Sciences, Vol. 4, Elsevier Scientific Publishing Company, Inc., Amsterdam, 1973. [Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 135–144.]
Nicholas Gall, David Newman, Philip Allega, Anne Lapkin, Robert A. Handler. (2010), ‘Introducing Hybrid Thinking for Transformation, Innovation and Strategy’, Gartner, 13 April 2010, Number G00172065.
Postscript 17 Jan 2013: I recently discovered this blog on problem-centric thinking — well worth watching: http://problemsfirst.com