How Design Works

The Problem of “The Problem”

Wicked problems are problems that defy definition. They are too complicated for any one person to understand in their entirety, they span organizational and group boundaries, and call upon knowledge from multiple, specialized areas of work. We only ever understand a small part of what people in other groups and departments do. Solving a wicked problem is like piecing together a jigsaw puzzle — without the picture on the box. A wicked problem cannot be defined objectively, for all the reasons identified in Figure 1 (see the page discussing wicked problems for more detail). Solving a wicked problem needs business users and stakeholders to engage in a joint process of argumentation, in which they explore and understand what problems that they face, their priorities in resolving these, and their change-goals.

A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing these solutions may make other, related problems worse or better. This is why iterative design is central to resolving wicked problems.

Design goals emerge as we understand the problem

In general, stakeholders don’t understand what they need until they see it. So solutions must be designed flexibly, for changes to be implemented as the consequences are realized and to permit adaptation-in-use by stakeholders and users. Improvisation takes a multitude of forms. It might be that a user wishes to customize the color of their screen (because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the first step, then go back later to change this, once you have the real data. This is because IT systems designers treat software design as a well-structured problem. A well-structured problem is one that contains the solution within its definition. Defining the problem as a tic-tac-toe game application means that you have a set of rules for how the game is played which absolutely define how it should work. This is fine if everything goes to plan, but a huge pain for users when it does not. The only discretion left to the user is how to format the results in a printed report, which is not much comfort if your whole transaction failed because you were prevented from going back to change one of the inputs. This is not rocket science – developers need to design systems that let users work autonomously.

Which means that new design-goals emerge periodically, and other goals are discarded as designers realize they are no longer a good fit with the problem, as shown in Figure 2.

The designer starts by designing for the subset of goals they understand. As they explore and test the design with users, they become aware of new requirements and so modify the subset of goals they are designing for. As part of this process, they also discard any requirements that are no longer associated with perceived user needs.

Design problems and solutions evolve in tandem

We talk about design as if it were fixed: as if there were a clear set of rules for design – one best way to design everything. We celebrate designers who produce especially elegant or usable artifacts as if they were possessed of supernatural powers. Yet design is just the application of “best practice” principles to a specific situation. We can observe how the users of a designed artifact or system work, then design the artifact or system accordingly. Why does that approach fail so often?

The issue with design rules (and patterns) is that they only deal with well-defined problems

We have understood for a long time that problems and solutions tend to emerge in tandem, during the process of design. Designers acquire a repertoire of design-elements-that-work: patterns that fit specific circumstances and uses. Experienced designers are capable of building up a deep understanding over time, of which problem-elements each of these patterns resolves. So they can assess a situation, recognize familiar problem-elements, then fit these with design patterns that will work in these circumstances. This process is shown in Figure 3.

Figure 3. Design Problems and Solutions Emerge in Tandem

The process breaks down when a designer is faced with a novel or unusual situation that they have not encountered before. Novice designers encounter this situation a great deal, but even experienced designers must deal with emergent design in a novel context. In these circumstances, designers iterate their design.

• They start by identifying partial problems, ideate/conceive relevant solutions, give those solutions form with a prototype, then evaluate the prototype in context. This often reveals emergent user needs or problems, that are explored in the next iteration.
• If that strategy does not work – usually because the designer just has not encountered similar problems that they can extrapolate from – the designer will call upon external expertise, consulting colleagues, resources such as design websites and online experts, and their extended network of design contacts. This often suggests alternative design approaches they can try.
• Finally, if they still don’t have a solution, we know (from extensive research into the psychology of design) that designers will reframe the problem to fit available solutions. They will change the design requirements to fit a problem they can solve, rather than spending additional time and effort searching for solutions and experimenting with prototypes.

Most contemporary design approaches are cyclical to , This process is intended to be linear within cycles of design, with whole-cycle iterations that allow stakeholder involvement in evaluating prototype solutions, providing additional design goals and requirements as they understand the way in which the designed solution will work, and suggesting areas that the designer has overlooked (remember, this is a wicked problem …).

But in reality, iterations occur within cycles. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and to understand which design elements will work or fail in that situation, looping back to remediate the design as they spot logical flaws and gaps in the design. They may get as far as building a prototype, then realize that the designed solution will not work and loop back to change their solution – or redefine the problem(!). They may be in discussion with users to evaluate the prototype and realize that they missed a critical design need, causing them to loop back to the ideation stage so it can be integrated into the design. All of these events occur in the course of a “linear” design cycle. Because design requirements are emergent, the ordered process that was planned for this design project turns into a completely different process than the linear design-process planned for each cycle: spirals within spirals, within spirals. There is even a name for this: the “loopy-linear model” of design (Friedman & Cornford, 1989). The resulting design process is shown in Figure 4, illustrated using the stages of a typical cyclical, user-centered design approach.

As the Princess said, you have to kiss an awful lot of frogs to get a Prince. An awful lot of people end up with really bad designs, because their designer did not recognize elements of the situation well enough to understand which pattern-elements to implement – and because they were trained to believe that design is a linear process within cycles. Only very few designers understand that their design artifacts and systems will be adapted and improvised in use. They resist changes to “their” design, which arise as users gradually understand how the system will work for them.

People are infinitely improvisational. They develop work-arounds and strategies to manage poor design. But, as Norman (2013) observes, why should users have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on flexible work-procedures?

• The problem of the problem: We have no objective problem definition Organizational change problems are wicked problems. The design constraints that result from the social and political nature of wicked problems (shown in Figure 3) create a more complex and iterative process than the design of well-defined technology that employs a more reductionist approach.
• Design goals emerge as we understand the problem: It is difficult to manage design in situations where design goals evolve as you understand more about the context in which a design will be used. You are trying to hit a moving target.
• Design problems and solutions evolve in tandem: we know (from a whole bunch of research) that designers (in all fields, including IT and business analysis) work by conceptualizing how parts of a solution will work, then fitting those parts to parts of the problem. If they don’t find a fit, they ask other designers. If they still don’t find a fit, they are more likely to reframe the problem than to start over with a clean slate.

We need to develop approaches that allow us to visualize, debate, and understand multiple perspectives of “the problem” in order to manage the evolution of design goals and requirements.  Improvisationally.

References

Friedman, A.L. and Cornford, D.S. (1989) Computer Systems Development: History, Organisation and Implementation, John Wiley & Sons

Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books, New York.

Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4, 155-169.