Selection of Quotations on Design Languages and

Their Relation to Design Layers 

Andy Gibbons and Clint Rogers

Instructional Psychology and Technology Department

Brigham Young University 



Purpose

Our main idea is that designers can profit by looking into the nature of designs. Each instructional design shares aspects in common with other instructional designs, and we have tried to identify two of these commonalities, described below under two main headings: design languages, and design layers. We will try to give substance to each of these ideas and show the useful relationship between them. 

We caution the reader that these ideas are not scientific, nor are they subject to demonstration by scientific means, so far as we can tell. Instead, these ideas are technological in nature: they describe generative principles that a designer can use in design synthesis. Technological principles (we will refer to them as technological theories or design-related theories) are not true, nor are they mutually exclusive. A designer may call upon multiple technological principles (theories) in the making of a single design. The existence of one technological principle does not invalidate the existence of other technological principles in the same way that one scientific theory tries to eliminate others from consideration. (See Gibbons, 2003b for a discussion of this view.) 

The reason for this caution is that the discussion may try to slip into the scientific “proof” metaphor, which will cause the discussion to stop making sense. Our goal is to explain the utility of thinking of design in terms of design languages and design layers. We will feel successful if these ideas allow you to think of designing in a way that improves the cost of designing, the quality of designs, or the time required to design; and we don’t want you to give up ideas that already work for you. 

The most economical way for us to proceed is to provide key statements from our existing work that express the gist of the argument. The reader may find that this initial statement needs more explanation, and in the discussion that follows during the week we will try to provide answers. 

Design Languages

“Design languages, formal or intuitive, lie at the heart of all design and development processes and tools. Instructional designers tend to be unaware of the multiplicity of design languages they use, because in most fields the use of design languages to improve precision and productivity is relatively new. However, the identification and use of design languages in many design and manufacturing fields has greatly benefited the growth and maturation of many fields over a very short span of years. Instructional design will also benefit from this trend as designers and theorists become conscious of the existence and application of design languages and their related notation systems.” (Gibbons & Brewer 2005, p. 111). 



A design language is a set of abstractions used to give structure, properties, and texture to solutions of design problems. Design languages provide building blocks for designs. Design languages provide categories for thinking about design problems. Design languages provide an important link between technological theory and design practice. Design language terms signify objects to be acted upon, actors, actions, concepts, types of relation, composite objects, qualities, and properties. 

Consider the following scenario illustrating a typical design situation:

As instructional designer you are asked to support a communication specialist in the design of a blended learning course in effective communication skills for a company’s workforce. At a meeting you and the communication specialist are discussing lectures, discussions, case studies, exercises, online discussion forums, and other possible activities. As the discussion proceeds, you realize that the communication specialist does not recognize some of these terms. Further, you realize that the definitions of the terms that you do both recognize differ, sometimes in significant ways. You begin to find it hard to discuss design details because you are not yet working from a common framework of meaning.”

The designer and the communications specialist need a shared set of terms for shaping their design that will be understood in roughly the same way by both. The designer and the communications specialist will draw on personal and public design languages from each’s own training and experience, and new terms will be invented within the scope of the project. A shared language will evolve through a negotiation process common to design in every field (Winograd & Flores, 1987). Notation systems that include drawings, symbols, and words will also evolve to publicly represent the design. This notational expression will be directed toward a specialized audience whose members know the language and its notation well enough to understand the implications of the design for manufacture. The design documentation will therefore be rich and dense and difficult for non-team members to interpret.” (Gibbons, Botturi, Boot, & Nelson, in press). 

We should emphasize that what will result from this negotiation will be a project-specific design language that has been worked out by the design team. Within this language will be terms that are commonly used by designers, but the negotiated meaning will be the project’s own, and the meanings that evolve for the project will have much more agreed detail than the general-use terms. Our common design languages, therefore, are generalized abstractions that have a certain somewhat-vague structure and lack detail. That detail is added through the negotiations of individual teams as they try to find ways to use the patterns supplied by the abstractions to specific design problems. 

The building block metaphor does not refer to Lego™-like blocks that simply join together mechanically: it refers to abstractions that can be combined together into a design in a way that the identity of a single abstraction can be lost but still act as a modifier to the whole design. We will try to make this idea more clear later on. Christopher Alexander (1979) provides an example of how terms from a language of design patterns can be combined to create a house design. This theme has been taken up in some parts of the software industry (Gamma, Helm, Johnson & Vlissides, 1995; Gabriel, 1996; Van Duyne, Landay & Hong, 2003). 

It is a truism that designers do not invent anew the primitive elements of their designs each time they make one. Instead, they work with a familiar set of primitive structures at some level of granularity that they tend to use and reuse from design to design. Whether the designer is conscious of using these primitive building blocks or not, they constitute the primitive terms of that designer’s design languages. What is less often the case is that designers are conscious of multiple such languages that they use and decompose their design problems into sub-problems in terms of the different languages they hold.” (Gibbons 2003a) 

Design Layers

Most instructional designers do not think of their designs in this way, and the literature on instructional design does not teach it. The problem that asserts itself when a designer does begin to think in terms of design languages is that it becomes apparent that there are literally hundreds of languages that every designer uses: most of them implicit languages embedded in habitual or traditional design practices.  

Schön (1987) describes the organization of these languages into “domains”.  Each domain represents a particular design sub-problem to be solved, and the languages of the domain—which may be many and varied—supply different sets of constructs that can be used in framing a solution. 

Table 1 below provides a sampling of the many domains Schön names that are related to the solution of a problem in architectural design.   

Table 1. Schön’s domains of an architectural design (excerpted from Schön, 1987). 


Domain

Definition

Examples

Siting

Features, elements, relations of the building site

Land contour”, “slope”, “hill”, “gully”

Organization of space

Kinds of space and relation of spaces to one another

A general pass-through”, “outside/outside”, “layout”

Form

1. Shape of building or component

2. Geometry

3. Markings of an organization of space

4. Experienced felt-path of movement through a building

Hard-edged block” 

A geometry of parallels”

Marks a level of difference from here to here”

Carry the gallery through and look down into here, which is nice”

 

Structure/technology

Structures, technologies, and processes used in building

A construction module for these classrooms” 

Building character

Kind of building, as sign of style or mode of building

Warehouse”, “hangar”, beach cottage” …

Building elements

Buildings or components of buildings

Gym”, “kindergarten”, “ramp”, “wall”, “roof”, “steps”

 

Notice that the right-hand column (which is Schön’s) contains an assortment of terms used within the domain to supply solution constructs. These are a very small sampling of terms from the design languages that pertain to each domain. Schön describes the design community’s relationship to languages in this way:

Aspiring members of the linguistic community of design learn to detect multiple references [language terms], distinguish particular meanings in context, and use multiple references [language terms] as an aid to vision across design domains.(Schön, 1987, p. 61)

“Brand (1994) also shows how the design of buildings may be approached in terms of separate but connected and aligned ‘layers’. A similar layered structure of designs can be found in many other design fields as well, not because it has been invented there, but because it is the nature of designs to be so structured (Schön, 1987).” (Gibbons, 2003). 

Layered designs can be found everywhere: basically in any design field. Computers are designed in terms of layers, as is the software that operates on the computer. Originally software was physically built-in to computer hardware. It was a major technological discovery that the software structures could be abstracted away from the hardware. The layer principle is inherent in the modular structure and economics of the digital world described by Baldwin and Clark (2000) in their book Design Rules: The Power of Modularity.    

Approaching design problems in terms of domains (layers) and the languages that pertain to them opens up a new way of thinking to the designer. It means that design problems can be addressed in terms of the functionalities of the thing being designed, rather than in terms of the process used to design it. Instructional designs have many things in common:  

 

The functions we have listed are carried out by virtually all instruction through a combination of human and technological means and therefore must either be designed or defaulted. One of the purposes of describing design languages and design layers (domains) is to bring more of our design decisions out of the default category and into a public process, which may be totally human- or team-determined or in which some of the design decisions can be aided by automated means.   

To describe what we see as the benefits of layer-language thinking, we will resort to quoting again: 

Several benefits may be expected from [design language] research: 

 
 Andy Gibbons

http://webpub.byu.net/asg33/index.html 
 



References 

Other reading