11.2 Elements of Reflective Design

Schon embeds design into what he calls an epistemology of practice, "reflection-in-action." For simplicity, I'll use the term reflective design to cover an extended view of design that folds the key aspects of reflection-in-action into his discussion of the details of design.

For the details of design, I'll rely on Schon's description and analysis of an architectural design session between a teacher and a student, his example for introducing those details. He uses the session as a starting point because "architecture is the oldest recognized design profession, and, as such, functions as prototype for design in other professions" (1983, 77).

Not all of Schon's discussion of design in architecture maps easily to systems design. But his analysis of the design process provides an important starting point for examining otherwise unstated aspects of design as a personal process, to use Watts Humphrey's term process from a personal perspective rather than an organizational one.

The practice of design should be as important in shaping a modeling language and its application as the technical goals that it is meant to support. As a working tool for modeling, the UML needs to be consistent with the working practices of designers. Also, given the fast and loose way that writers on the UML talk about architecture, his example also provides a fascinating example and explanation of real architectural thinking. It can provide a valuable antidote to the representations of architectural practice that are out there.

Schon (1983) identifies a number of elements in reflective design that combine to define professional practice:

Problem setting
A language of design
A language about designing
Performing
Closure

I'll use these categories to explore the way Schon's elements of design combine to form a practice, and how the UML and patterns can support reflective design.

These categories are my own and may be considered somewhat restricting and limited by anyone who's really familiar with Schon's work. Schon's fluid, almost anecdotal style masks a subtle architecture in his writing that makes simple summarization difficult. His writing is better approached as music to be played, where a not-always-obvious shaping comes from a gradual appreciation of phrasing that often has to be coaxed out of the material.

As categories, they're useful because of some obvious parallels with the formal processes that most developers will be familiar with. However, they should be seen as interconnected and in some ways overlapping, rather than as separate activities. Certainly, in Schon's writing about design, they appear and reappear in recursive and iterative fashion, to be applied improvisationally as surprises pop up.

11.2.1 Problem Setting

A designer is initially presented with problematic situations rather than problems situations that are "puzzling, troubling and uncertain" (Schon 1983, 40). The first step in reflective design, then, is to make sense of the situation, to construct its reality, and provide a framework for understanding and interacting with it. This sense-making is not technical. Problem setting "is not itself a technical problem" (40). Means and ends are "framed interdependently" (165).

Schon adds:

When we set the problem, we select the things we will treat as the "things" of the situation, we set the boundaries of our attention to it, and we impose coherence we name the things to which we will attend and frame the context in which we will attend to them. (1983, 40)

But problem setting is not merely the establishment of a context. It is an active framing of the situation that at least implies some elements of the design that will result. In framing the situation, the designer brings to the "framing experiment" the practitioner's repertoire of experience and knowledge models to start from.

This description should resonate immediately with UML modelers and patterns users.

The question of architectural style is dealt with early in any process using the UML. This can be considered part of the framing because, to repeat what the UML Specification says: "(t)he choice of what models and diagrams one creates has a profound influence upon how a problem is attacked and how a corresponding solution is shaped" (Rational Software Corporation 1999, 1 3).
The identification of business objects and/or types; the establishment of context via actors, events, and interactions; and the focusing of attention via use cases are all aspects of problem-setting when modeling with the UML.
The clear separation of analysis from design, coupled with a lengthy postponement of implementation concerns, is being replaced by iterative, recursive cycles of analysis and design, interleaved with an early focus on architecture.

In using patterns, problem-setting is explicit. You start by creating your own small pattern language from all the patterns available. According to Alexander, Ishikawa, and Murray, "the character of what you build will be given to it by the language of patterns you use" (1977, xxxvii). A pattern language is local; it starts when you begin to build or design.

Each pattern is a miniature frame, containing elements that help with the mapping to a situation. In particular, there should be a mapping of the forces in the selected patterns to forces in the situation, in an effort to establish congruence between patterns and the situation. Successful mappings help "frame the context," and so help create a basis for conceptual coherence in setting the problem appropriately and fittingly.

11.2.2 A Language of Design

The "conversation with the situation" that Schon refers to is, of course, not meant to be taken literally. He's describing the back-and-forth, give-and-take interaction between the situation and the designer. The dialogue between the two takes many forms, but always involves more than just drawing. Think of the whiteboard as a medium for interaction.

In the same way that models are both text and graphics, a language of design involves "drawing and talking [as] parallel ways of designing" (Schon 1983, 80) that is local to a situation not generic like pattern languages. The emphasis is on a language of design, not the language of design.

In some ways, a language of design bridges the gap between a generic modeling language such as the UML and a generative pattern language. The verbal and nonverbal interact, especially in the performance of collaborative design activities. Nonverbal information is reinforced, enhanced, extended, and clarified by informal verbal information. In successful projects, verbal and nonverbal shorthand eventually emerges in the form of a dialect. Models become repositories for dialects, parts of which may be more private, whereas other parts may be public in varying degrees. Some of the information may be formalized and recorded; some of it will be temporary and improvisational.

In using the UML, this back-and-forth interplay among model, modelers, and clients is critical. Rather than simply being archival documentation, models are used to facilitate this interplay. Tactics such as the elision of unnecessary detail, local and temporary stereotypes, and the use of notes can play useful roles in the process. Scenario-building and exercises such as CRC cards can be powerful tools in the emergence of a language of design for a project.

Unlike traditional architectural drawings, UML models are deliberately both text and graphics. Furthermore, the UML explicitly encourages the use of hyperlinks as a way of building connections and facilitating conceptual navigation. Thus, the UML provides tools that can augment a language of design in a variety of ways. Some of this can be formalized, but only after the fact. For example, Catalysis provides a construct a stereotype of package called dialect, which supports such formalization (D'Souza and Wills 1998).

Patterns, of course, can supply much of the rich vocabulary that can be the base for a language of design. Public patterns can be reused; variations can be introduced that reflect local conditions more closely; private patterns that are local to the design dialect can be created.

The process of creating patterns is itself an aspect of a language of design. Workshops, study groups, and other activities that have evolved as sound ways to surface and evolve patterns can be part of the development of a language of design.

11.2.3 A Language about Designing

Schon carefully distinguishes "a language of design" from "a language about designing a metalanguage" (1983, 81). This too needs to be a part of practice. Professional practice isn't just about the personal responses of practitioners to local situations; rather, it too has a larger context, which is the context of the practice itself. Ideas about the nature of competency are interwoven into the interactions that take place, and provide some of the framework for communicating the results. Professional standards, exemplars that provide guidance, and heuristics all need to be available as part of the design conversation.

Again, both the UML and patterns provide different ways of addressing this need. The UML explicitly responds, via the metamodel and Specification. Patterns can be found that exemplify both "a language of design" and "a language about designing." And finally, mentoring and pattern-writing are ways to include a language about designing into every designer's practices.

11.2.4 Performance

Problem setting and naming-and-framing lead to a set of performed responses to the situation. Schon uses words such as move, stance, and sketch to indicate the performative utterances and actions that a designer engages in.

He leverages the ambiguities of the word performance the same way he leverages similar ambiguities in the word practice. For him, performance is both successfully creating an end product and the artistic doing of it. The reflective designer is engaged in a dance with the client that must also produce tangible results.

Having a problem framework as a starting point and a domain language as a beginning point to design is still just being at the starting line. The designer has to "perform" design to act in collaborations, draw, write, and, ultimately, architect a whole that is greater than the parts.

The following sections discuss the essential elements of design performance as Schon portrays them.

Moves

A move is a design action that produces potential problem-solutions in miniature with consequences that need to be appreciated and implications that need to be understood. Moves are the increments of design that, like models, "give us the opportunity to fail under controlled conditions" (Booch 1994, 22). The important thing is to be able to see the changing whole, as well as the parts: "[e]ach move is a local experiment that contributes to the global experiment of reframing the problem" (Schon 1983, 94).

The process is like a chess game that redefines its rules as the game proceeds. This is where "back-talk" comes in. The situation may "resist" the move; that is, the move may not contribute to the quality of the overall solution. The evaluation of a move may reveal unexpected consequences some useful and some not.

The language of design provides the vehicle for communicating and assessing these moves. Schon suggests that a designer use categories to organize both her moves and her responses. He calls these categories design domains; each domain corresponds to an area of concern and an aspect of the repertoire of experiences and knowledge that a professional brings to the situation. A domain organizes the questions that need to be asked: What will the costs be? What name should I give this design element? What form should it take? Is it like anything else I know about or that I've done?

Consequences

Each move results in changes to the situation that need to be expressed. They also need to be explained and assessed, both as intentions and by examining unintended consequences, by using the language of design within the design domains at hand. Past experience and intuition both come into play in examining how a design change or addition might have consequences.

Schon uses the term appreciation to describe the designer's act of considering the possible effects of a move. This term captures the intuitive and aesthetic aspects of the designer's reflective performance in a way that assessment or evaluation doesn't. Appreciation includes a sense of fit and quality, as well as a consideration of the effects at the global scale not just an identification of the local impacts from a technical perspective.

So, the designer has to be able to see the whole, feel the qualities present in the whole, and work in terms of the ongoing evolution of the whole not just be buried in the parts.

Implications

Having considered the intended and unintended consequences of a design experiment, the designer has a decision to make about committing to the results. The designer has a variety of options: accepting the move, reframing the problem, or adopting a new stance in considering the consequences (revisiting the appreciation).

Whereas the process in considering the consequences was one of appreciation, the process at work in considering the implications is more one of testing. When a decision is being made, the implications of the decision have to be worked out and evaluated in the context of the implications of past moves: "(T)here is a literal logic of design, a pattern of 'if then' propositions that relates the cumulative sequence of prior moves to the choices now confronting the designer" (Schon 1983, 99).

The set of implications built up over the course of design moves creates its own complexity the complexity of all the decisions and their implications through the life of a design. Schon describes this complexity as the "web of moves" in which "systems of implications" become "disciplines" for the design process (1983, 131).

Any decision establishes what might be called a new conceptual baseline that will be used in considering future moves. These baselines are, of course, not cast in stone. The designer doesn't have to honor the implications of previous moves. They're there to facilitate consistency, coherence, and fit, and to help manage the complexity of the "web of moves."

If a new move has been appreciated as sufficiently special in some way, then it can violate the logic of the design. It establishes a new logic, perhaps, or creates a new discipline to impose on the process. If the move is not sufficiently special, then reframing the problem or revisiting the appreciation may be needed:

Reframing the problem permits a designer to review the problem setting and attempt to fit the situation into a new way of understanding the problem. Reframing may take the form of reflection-on-action or reflection-on-practice two additional types of professional reflection that I won't deal with in detail. Essentially, reflection-on-action takes place outside of the ongoing design process, whereas reflection-on-practice might include questioning the nature of the design practice itself.
Revisiting the appreciation provides an opportunity to reconsider the consequences of the move, perhaps by looking at the prioritization of the design domains used in making the appreciation of the move.

11.2.5 Closure

Reframing the problem or revisiting the appreciation may lead to reiterating the process of moves consequences implications, or the designer may move on. A degree of closure occurs. What Schon calls the stance of the designer toward the design changes; the designer commits to certain aspects, their implications become more fixed, and there's a shift in the attention paid to specific design domains, typically toward those domains concerned with building and away from conceptualizing. At the same time, however, because of the interactive and exploratory nature of the process, new questions may have been raised and new opportunities identified.

Closure is never final; it is useful and subject to the results of further design iterations. Closed problems may need to be reviewed and reworked down the road. But there is an implicit understanding that design decisions have been made, and it is time to move forward.

11.2.6 Reflective Design and Systems Modeling

The design process I've summarized doesn't have any obvious connections to the main artifacts of the UML. However, it is implicit in working with the UML properly. It can be seen "in action" in many of the books about system design that have case studies illustrating how the work of design is actually carried out both pre-UML and when using the UML.

Two good examples of moves consequences implications from before the UML are David Taylor's Business Engineering With Objects (1995), and Nancy Wilkinson's Using CRC Cards: An Informal Approach to Object-Oriented Development (1995). The best example that deals specifically with using the UML is Applying Use Cases: A Practical Guide, by Geri Schneider and Jason P. Winters (1998). The "moves" described in the latter book about establishing an initial architecture of subsystems is an especially good description of architectural performance as reflective design.