On Complexity

Not to be glib, but recognizing and working with complexity is kind of a wicked problem.1  But these skills are also an integral part of design practice in the current era. As designers at strategic levels, we must grapple with complex issues constantly, but, at the same time, we must recognize the scale of complexity and be able to parse whether a situation is, in fact, actually complex or if instead it is complicated or even simple, despite its first appearance.

First, let’s do a brief breakdown of simple, complicated, and complex that I first explored in the HCD Design Phase Operations Guide. I’ll also used the unexpectedly prosaic example of the field office of the Department of Motor Vehicles (DMV) in Glendale, California as an exemplar of each each of these abstractions in order to bring them down to a concrete level. In brief, I perceive the difference between these three levels of problem state as:

• Simple: A simple design is one that can stand alone, without core dependencies on any other product, service, or system that will make or break its success.

  An example of a simple problem at the DMV is the driver's license card. The card is a simple design problem: get every person’s eye color, hair color, height, and a few other items onto the card. Is it a massively scaled problem? Yes. Is it a perfect fit for every individual in the U.S. who wants a license? No. Can it be improved? Yes. But as a design problem, the card itself and the information on it is pretty simple.

• Complicated: A complicated design is one that has many parts that all have to work in unison for the designed thing to function. Those parts are stable and have defined boundaries, so they will not shift in nature very often. But as with any system of parts, both the parts and the meeting points of those parts can shift. This makes complicated systems prone to frailty over time. This means complicated designs require some regular oversight to maintain high function.

  The example of a complicated problem at the DMV is the organization of the lines to wait in. The DMV knows what lines it needs at a California field office. What it doesn’t know is how to arrange them all inside the building they have on the plot of land they have. To fit enough line areas, processing areas, waiting areas, bathroom areas, staff areas, et cetera, for the anticipated amount of people the field office will serve in a uniquely shaped building is a complex problem: the systems involved, architecture and DMV needs, are fixed and won’t shift very often. But the designers of the space must make them fit together. Once that’s worked out, however, the design won’t need to shift very frequently.

• Complex A complex design is one in which many, sometimes competing, sometimes themselves complex, systems come together.

  Finally, the complex problem at the DMV, and it is a terribly, horribly overlooked problem space: the parking lot. In the DMV parking lot, multiple complex systems come together to form another complex and dangerous system space. In the lot, you have people entering at speed from the nearby freeway; others come in slower from the city streets. Meanwhile, people with no mobility issues walk briskly in and out of the building, while others with canes or wheelchairs or children go slower. Some people want to stay and picnic under the trees; some people want to grab lunch in their cars. There are corners to navigate and people backing their cars up, minds already intent on their next task. Multiple systems come together and must mesh. And that’s an example of complexity.

Given the pitfalls of complex systems and the frailty of complicated ones, it’s clearly preferable to design simple products, services, and systems whenever possible.2 

In complex spaces, which all organizations are and the federal government undoubtably is, I advocate for a strategic practice of developing simple designs that can stand alone.3 

By these means, designers precisely define the problem(s) their designs are meant to affect and design within a bounded space. The strategy backing this approach is that all the simple designs are deployed across time but in concert. Over time, their accumulated affects can make real change in participants’ experience using the product, service, and systems from the organization.4  In this way, well-researched, precisely scoped problem spaces to help us to address the inevitably complex, human issue a design team in a complex organization is attempting to solve.

1. Buchanan, Richard. Wicked Problems in Design Thinking. Originally published in Design Issues, vol. 8, No. 2, (Spring, 1992), pp. 5-21. Here is a link to a pdf of Wicked Problems in Design Thinking
2. This sounds easier than it is. For more on this, please see the HCD Global Design Principle, Getting to Simple is Hard (link to beta). This principle was first articulated in the UK Design Group’s design principles.
3. In 18F, the General Services Administration’s digital product and service design shop, their mission statement “Delivery is the strategy” encapsulates this idea. This is that the core purpose of a design team is to deliver the best solutions possible for the project at hand.
4. Of course, this process creates a complicated system, which requires maintenance, as discussed in the Designed Things article. But maintenance and sustainment should be parts of the design process, not an afterthought. For more on this, please see the Design for Change principle from the HCD Design Concept Guide.