Dynamics between elements of design activities lead to complexity characteristic for design activities. While design situations, outcomes and resources are themselves complex structures, what makes a design activity additionally and characteristically complex are interactions among these structures. As illustrated with our patterns of dynamics, these interactions challenge designers’ ability to deal with complexity as any of these structures is subject to change, in difficult to predict ways.

One of our central assumptions is that design complexity, as a consequence of dynamics of design activities, should not be seen as a problem. We are not alone to make this argument. Fred Brooks (1987), for instance, claimed that descriptions of a (software) design that abstract away its complexity often abstracts away its essence. Consequently, we view the dynamics and unpredictability of a design process as a defining characteristic of any design activity. Moreover, we believe that a lack of stability is a requirement for any process to be called design. If a process is more predictable and stable, we would typically not see it as a design activity. Or, at best, we would call it a routine design.

In many ways, unpredictable dynamics of design activities is exactly the state that designers want and need. A fast-changing world, while being complex to understand and work with, is a rich source of design opportunities. Designers are expected to create new, surprising and creative outcomes in domains where conventional, more structured approaches may not work. They are supposed to dive into new areas, to push the limits, rather than operate in standardized and well-understood domains. This expectation, by necessity, leads to an unstable process, in the sense that it is not possible to fully prescribe or control it.

The key question is not how to make design activities stable and entirely predictable, but how to deal with the resulting complexity. In general, we can deal with complexity in two fundamental ways: develop tools to reduce it when we can, or learn to tolerate it when we cannot (Rubinstein 1986). Both of these ways are relevant for designers. The design research community has been working on developing tools to deal with different forms of design complexity (e.g. Stolterman 2008, Montagne 2010). In software design, for instance, lots of attention has been given to tools that can help developers to avoid creating unnecessary complex system implementations (Brooks 1995). However, less attention has been given to acceptance and tolerance of design complexity itself. Robert Glass (2006) claimed that it is unusual to find tolerance for complexity among managers, entrepreneurs, and maybe more surprisingly academics (page 104). The majority seems to be looking for simple and elegant solutions. Glass, however, argued, as we do, that we should accept complexity and ambiguity in design, rather than trying to wish them away.

Accepting design complexity does not mean ignoring it. On the contrary. Accepting complexity has to be combined with more awareness about it. There is a strong need to be more considerate about design complexity and its sources, and invest more time in understanding and coping with it. We want to increase awareness about complexity and its origins in design. Furthermore, we want to stimulate designers and design researchers to approach the issues of design complexity more thoughtfully.

Our patterns of dynamics also highlight the need for holistic approach to designing. Many forces shape and influence design activities. Without a pro-active approach to manage and balance impacts of these forces, we may end up in design activities that are driven by hype, fashion, and politics rather than by the value delivered to users.

In addition to increasing the awareness, we believe that our framework and patterns can give some insights about why particular design approaches are more (or less) successful in dealing with design complexity. For example, most designers are well aware that due to the highly-interdepended nature of design situations, outcomes, and resources, it is not possible to work on one part of the design in isolation. For instance, two of the most recognized design scholars Lawson (2005) and Schön (1990) argued that design problems are rarely simple problems with only one or two features, but that a whole host of criteria must be satisfied and a multitude of constraints respected. Lawson concludes that “the only way to keep them all in mind at once, as it were, is to oscillate very quickly between them like a juggler.” (page 151). Lawson also cites Michael Wilford who compares architects to jugglers: “’[a juggler] who’s got six balls in the air . . . and an architect is similarly operating on at least six fronts simultaneously, and if you take your eye off one of them and drop it, you’re in trouble’.“ (page 151)

Experienced designers already understand that the “conventional” ways of dealing with complexity cannot always be applied in design. For instance, one of the most common approaches to deal with complexity is a separation of concerns often called a divide-and-conquer approach. In this approach, complex objects are divided into smaller more manageable pieces. Each of the resulting less complex pieces can then be handled more or less independently of other pieces. Hierarchical organizations of systems, in general, follow this approach. In design, however, it is normally not possible to easily decompose problems into smaller chunks that can be solved in isolation. Advanced designers are aware that it is normally not possible to be a reductionist. In design, it is usually not possible to reduce complexity by splitting the problem into smaller chunks that designers can more easily handle. Frosh nicely illustrates this issue with his view on systems engineering and systems analysis (Frosh 1969):

“One of the key misassumptions in modern systems engineering and systems analysis is that the total problem can, and frequently is, decomposed into sub-problems; the sub-problems can be solved more or less independently, and the total solution can be synthesized by combination of the sub-solutions, treating the interactions of the parts as ‘interfaces.’ The real world is, however, highly nonlinear, and unless real attention is paid to this fact, the linear decomposition treatment will fail catastrophically, because the interaction terms may be as large as the sub-problems and not reducible to simple interfaces. The result may well remain decomposed.”

Similarly, Rick Nason, in his discussion on complexity in business, noted that complex problems involve too many unknowns and too many interrelated factors to reduce to rules and processes (Nason 2017). Hendler et al. (2008) also noted that complex systems have emergent properties that are not predictable by analyzing micro technical or social effects.

Design complexity, thus, needs to be addressed with other approaches than decomposition and reductionism (e.g. Sommerville et al. 2012; Stolterman 2008).

Experienced designers are aware that a designer never has enough information to predict any aspect of a design reliably, and that it is therefore not always a good idea to spend much time analyzing and theorizing about solutions and potential consequences. Instead, attempting a solution, making mistakes and learning from them is one of the most important strategies that any designer use (e.g. Ball et al. 2010; Gaver et al., 2009; Buxton 2007; Lamer 1989’ Linden 2010). Henry Petroski, for instance, argues that the old dictum “form follows function” is false and that the basic rule of design evolution is “form follows failure” (Petroski 1994: p 22). He argued that changes in the design, even for commonplace things like forks and paper clips, are more motivated by the things early designs do poorly than those things they do well. Such flaws guide design decisions, as each new design attempt is an attempt to correct flaws. In the domain of software design, empirical studies similarly showed that good software designers use a trial-and-error process. The purpose of this process is to create mental models of a design solution, while poor designers tend to seize on a solution with fewer trials and errors (Curtis 1987; Adelson 1986). Or, as noted by Sir Francis Bacon almost 400 years ago “truth will sooner come out of error than from confusion” (Bacon 1620).

Probably the model that most closely describes the challenges that designers face in dealing with complexity is the famous Simon’s (1996) model of “bounded rationality.” It is the concept that decision makers (irrespective of their level of intelligence) have to work under three unavoidable constraints: (1) only limited, often unreliable, information is available regarding possible alternatives and their consequences, (2) human mind has only limited capacity to evaluate and process the information that is available, and (3) only a limited amount of time is available to make a decision. Even individuals who intend to make rational choices are bound to make satisficing (rather than maximizing or optimizing) choices in complex situations. Decision-makers in this view are satisficing because they seek a satisfactory solution rather than an optimal one.

The bounded rationality model reflects very well the designers’ work. Designers are constantly making a complex design decision, in fast-changing environments. The world is changing fast, and designers need to make decisions before they fully understand design situations to avoid creating obsolete outcomes. And increased interconnectivity makes such changes quickly propagate in many parts of the world. Lately, there has been some advancements based on Simon’s ideas, such as the work of Hatchuel (2001). Hatchuel introduced the model that emphasizes, even more, the need to handle complexity as a designer, arguing that it is not possible to deal with complexity by being comprehensive. Instead, he argues for an explorative and judgment based approach.

We also see a strong movement from prediction based design management toward management that adapts to change. Initiatives, such as rapid prototyping and agile software development all emphasize the importance of constant adaptation to change. Ries (2011) noted that old management methods, such as long-term planning and forecasting, are not appropriate in dynamic contexts. As suggested by Hales (1985) designers need to be like chameleons, constantly adapting to dynamic environments.

Complexity in design means different things to someone who is a researcher and someone who is a practicing designer. Most researchers focus on one or a few of the patterns and their relationships. However, a practicing designer does not have such a choice. When engaging in real design activity, a designer cannot decide to only pay attention to particular patterns or relationships. A designer has to deal with the full complexity. The recognition that most design research only pay attention to some specific aspects of the complexity of design practice was one of the motivations for creating a framework that would make it possible to examine and discuss design complexity without losing the overall view.

We believe that it is crucial to educate designers to be more tolerant and thoughtful about design dynamics and complexity. We can learn from successful designers who have developed a range of approaches suitable for dealing with design complexity. We hope that our site can facilitate such knowledge transfer by providing the structure and vocabulary to describe and correlate complex design experiences.

Cover Art

Joggling (combined juggling and jogging). Designers are often compared to jugglers operating on several fronts simultaneously. Credit: Owen Morse / Wikimedia Commons.