Summary

Motto: “If you want to change something, you need to understand it, if you want to understand something you need to change it.” (Gravemeijer and Cobb 2006)

Type: A pattern of dynamics between Design Situations and Design Outcomes

Definition: A design situation and designer’s understanding of the design situation (problem definition) changes and evolves in parallel and under the influence of design outcome and designer’s understating of potential design outcomes (design solutions).

Alternative names: Problem–Solution Flux.

Topics: problems solving, problem setting, prototyping, iterative development, agile software development, reinventing the wheel

Desirable: In most complex real-world situations and new domains, as this pattern facilitates learning, stimulates communication among stakeholders, and minimizes the risk of failure.

Undesirable: In well-known domains, where it may lead to the “reinventing-the-wheel” and “not-invented-here” anti-patterns.


Description

Design authors generally agree that design situations are never clearly defined problems. Instead, the model commonly used is that of a co-evolution (Dorst & Cross 2001). In this model designers’ understanding of what the actual problem is evolving together with their attempts to create a solution.

Donald Schön (1983) was among first to argue that design is not a straightforward problem-solving activity. He elaborated that real-world problems do not present themselves to practitioners as givens (page 40). Instead, problem understanding must be constructed from the materials of problematic situations, which are puzzling, troubling, and uncertain1. Practitioners must make sense of unclear descriptions of situations that initially makes no sense. Schön emphasized that in design practice, problem setting is as crucial as problem solving.

Design authors also emphasize that a design situation cannot be fully understood unless some attempts have been made to change or improve the situation. Bryan Lawson, for example, claimed that many components of a design problem could not be expected to emerge until some attempt has been made at generating solutions (Lawson 2005: p 120). He argued that design situations are often full of uncertainties when it comes to the objectives and their priorities. These goals and priorities are likely to change during the design process as the solution implications begin to emerge. Lawson concluded that we should not expect a comprehensive and static formulation of design problems. Instead, we should see design problems as in dynamic tension with design solutions.

Herbert Simon (1996) stated that a goal of design might be to understand the problem and to generate new goals. He elaborated that the idea of final goals and a static problem definition is inconsistent with our limited ability to foretell or determine the future (page 162). Simon claimed that by designing without a fixation on final goals, and by adopting the stance to welcome new, emergent and originally unintended goals, design becomes a powerful tool for discovering new previously unforeseen goals (Chua 2015). As an example, Simon used an extensive renewal program in the city of Pittsburgh, where a principal goal was rebuilding the center of the town, the so-called Golden Triangle. Simon noted that the main consequence of the initial step of redevelopment was to demonstrate the possibility of creating an attractive and functional central city on this site. This demonstration was followed by subsequent construction activities that have changed the whole face of the city and the attitudes of its inhabitants. Each step of implementation created a new situation. The new situation provided a starting point for fresh design activity (Simon 1996, page 162).

Fred Brooks noted that it is impossible for a client to specify completely, precisely, and correctly the exact requirements of a software product before trying some versions of the product (Brooks 1995). Brooks claimed that the most challenging part of software design is deciding what to build. He went further to argue that a core service offered by a designer is not only providing a solution but helping clients to discover what they want (Brooks 2010, page 23). Empirical studies of software projects confirm these observations, as inadequately defined system requirements are among leading causes of software project failures (Charette 2005).

Classical design practices, such as sketching and prototyping, are mechanisms that stimulate co-evolution of solutions and problems (see Buxton 2007). Schön and Wiggins (1992), using the example of an architect, described that architect use sketching to engage in the “seeing-moving-seeing” sequence. This sequence consists of creating a drawing to represent an initial idea, observing a drawing, discovering “certain unintended consequences,” and reacting to this discovery by further transforming the drawing2 (page 139). With sketching, designers can, in relatively short time and with low costs, significantly improve their understanding of a design problem and possible design solutions (Obrenovic 2013).

In modern software development, a co-evolution is the primary pattern of dynamics behind the agile software development movement, nowadays a mainstream software development methodology. Agile software development promotes iterative and incremental development, using continuous feedback to refine and deliver a software system. One of the central values behind agile software development is responding to change over following a plan. This approach makes explicit the expectation that requirements (problem definition) cannot be fully known in advance, and will change during the project.

Because it stimulates learning and exploration, the co-evolution of problem-solution pattern is particularly useful in new domains, for which there are little known and documented experiences. The co-evolution of problem-solution, however, may be an anti-pattern when applied in well-known areas, where it may lead to the “reinventing-the-wheel” and “not-invented-here” anti-patterns (e.g., see Obrenovic 2017). In well-known domains, there usually are lots of documented experiences and best practices, and there are often standard solutions that can be reused. For example, for most organizations, it is costly and time-consuming to implement their custom solutions for tasks such as human resources management or communication (email, messaging). Typically, it is much easier and more cost-effective to adapt the organizational process to use standard off-the-shelf software solutions for these tasks.

The co-evolution of problem-solution pattern may be connected to the puzzle solving pattern. There it may occur during co-evolution of problem-solution as a way to find answers to specific well-scoped questions. The co-evolution of problem-solution pattern may also be related to the design-by-buzzword pattern. There it may occur as a way to develop a better understanding of useful applications for new design resources.

Questions to Ask Yourself

  • Do you continuously investigate, experiment, and iteratively refine your designs?
  • How do you resolve uncertainties about design objectives and their priorities?
  • Do you use sketching and prototyping extensively?
  • How do you estimate and plan projects with the co-evolution pattern?
  • How do you decide to design something new versus buying it off-the-shelf?
  • Are you reinventing the wheel by co-evolving solutions for well-defined problems with off-the-shelf solutions?
  • Are you guilty of the not-invented-here syndrome, routinely building yourself things for any issue you face?
  • Have you ever used the off-the-shelf solution that was not appropriate for your domain? What issues have you faced?

Cover Art

Pittsburg’s Golden Triangle. In the 1950s, an extensive renewal program began in the city of Pittsburgh, with a principal goal of rebuild the center of the town, the so-called Golden Triangle. Credit: U.S. National Archives and Records Administration / Wikimedia Commons.

Footnotes:

  1. Rittel and Webber (1973), for instance, claimed that real-world problems are “wicked” problems, were a problem cannot be defined until a solution has been found. Such problems are also sometimes called ill-structured (Reitman 1965; Simon 1973) or complex (Funke 1991). For readers interested in discussion on wicked problems in design, we recommend Buchanan 1992, Coyne’s (2005) and Farrell & Hooker’s (2013). ↩

  2. Goldschmidt (1991) further articulated this process, making a distinction between seeing-as and seeing-that moves in a “dialectics of sketching.” ↩