Commentary

The Puzzle Piece Meta-model

Hugh Dubberly’s May/June Interaction’s article provides a great survey of models and frameworks - a sort of meta-model of meta-models. It’s wonderful and I highly recommend it. (ACM Digital Library subscribers can see the full article online - here is the bibliographic reference with links to the online version for subscribers). I’ve spent most of my design career self-consciously considering the model I use even as I design the object itself. Our tools craft our models; our models craft our perceptions, and hence our designs are affected by the modeling frameworks we employ.

I prefer cyclical diagrams - I am a strong believer in spiral progression: we continue to revisit the same problems and situations, but never the same way twice. Linear models are too definite - most real world experiences are a continuum with no definite starts and stops. Even birth and death are stages in a continuum, depending on your point of view.

The Puzzle Piece Meta-model is a closed cyclical diagram with five parts. The outer four “puzzle pieces” interlock, each invading the territory of its neighbor. If I were more clever, I would have found a way of representing the pieces so that all four interlock with each other - perhaps as a star pattern, or maybe a 3D globe - because in fact, all parts of the framework touch all other parts. A decision made in one area depends on and affects decisions made in the other three areas.  The fifth part - the center - is the experience itself. It comprises the objects, artifacts, built environments, phone scripts and any other user facing elements actually delivering the experience. It is intentionally left blank as the experience morphs considerably over time and from project to project.

The puzzle pieces do not morph considerably over time. They change when the user population changes, the technology infrastructure changes, or the business model shifts. None of those move rapidly or dramatically compared to the myriad possible experiences an organization could deliver.

The diagram has several faults in addition to the aforementioned lack of total integration of all four pieces. It is too “slick” - its clean edges and corners suggest a finality and completeness that I’m quite certain is hubris. It’s not nearly architectonic enough for my aesthetic - it’s crude. But it’s sufficient to communicate to business and engineering stakeholders without my having to explain the meaning of each piece (even if I do have to explain the content of each piece).

Contrast my Puzzle Piece Meta-model with Morville and Callendar’s Treasure Map of User Experience Deliverables. Although their stated goal was not to develop a meta-model for user experience design, many of their deliverables map well into my puzzle-piece meta-model. As I describe each piece I’ll also reference example deliverables from the Treasure Map.
 

Quality Attributes

I don’t know from where I lifted the term, but I like it. It is used in lots of contexts. I like its multiple ambiguous meanings.

Quality - as in “peculiar and essential” characteristics, not as in “degree of excellence.” I use it to emphasize the non-quantitative aspects of the experience. So much of our training and guidance in user experience stems from gathering data. I included this adjective to reinforce the importance of emotive aspects of the experience.

Attributes - a way of purposely blurring the edges of the experience - the experience isn’t a set of things, rather it is a set of attributes that surround the thing. The phenomenological debate surrounding experience design (can we really design experiences, or design for experiences, or design contexts in which people have experiences, etc.) is not terribly interesting to me. I leave those distinctions to the philosophers. I do know designers and architects have been intentionally creating opportunities for others to enjoy and experience their creations for millennia. It is this self-conscious intentional act of creation I’m referring to with respect to designing experiences.  This quadrant of the meta-model describes attributes of the experience I hope people will discover, encounter and desire.

Put together, these two words describe the aspects of the experience that are emotive, non-quantifiable and create a long-lasting impression. The Quality Attribute piece of the puzzle covers key characteristics of the experience users expect, demand or desire.

To illustrate my point, consider two completely different design problems: a game and a rodent trap. For the game we are likely interested in creating an immersive experience with lots of “flow.” We’ll likely want to seduce the user and tease them as a way of enhancing their engagement. For the rodent trap, we will likely avoid seduction (for the human user, perhaps seduction of a different kind for the rodent), enhancing safety and security (again for the human, but also possibly for the rodent) and depending on the design, the humaneness of the device. In the first design problem we may wish to create an engaging experience for children; in the second we’d likely want to push children away.

Quality Attributes deliver the brand promise - the two are reflections of the other.

Nothing in the Treasure Map deliverables directly correspond to this aspect of the Meta-model although a few of Morville/Callendar’s deliverables include these qualitative aspects.

Models/Patterns

Most user research, usability and user-centered design activities and deliverables are part of this puzzle piece. Mental models, work models, contextual inquiries, most of the pre-design deliverables discussed in my last article all fall under this puzzle piece. This piece is where we determine and describe the users’ context, behaviors, work breakdowns and other artifacts to which our designed experience must respond.

Some would claim the models and patterns are the UX Architecture, but as I argued in my last article, while a crucial pillar in the structure they are not sufficient to comprise an architecture. If only the contents of this puzzle piece were the architecture, then Software Architecture would be an appropriate framework for a UX Architecture (since Software Architecture comprises many of the same kinds of deliverables contained in this section). But as the most recent article pointed out, Software Architecture is not a sufficient framework to support a UX Architecture.

Note how Quality Attributes integrate with Models / Patterns: if we believe a key Quality Attribute of our designed experience is to attract the user, we must have data, contextual models or other formalisms to support that position. The obverse is also true: an observation of our users’ habits must inform us as to what is attractive to our user base and hence inform our design direction accordingly.

Almost all of the Treasure Map components correspond to this portion of the Meta-model, including: Stories, Proverbs, Personas, Scenarios, Analytics, User Surveys, Concept Maps, System Maps, Process Flows, Story Boards, Wireframes and Narrative Reports.

Design Language

The Design Language we choose is crucial to expressing the experience itself. Our choice of colors and geometries, even our use of language itself are the direct interfaces people have with our designs. Whether we are designing an artifact, and environment or a new service, there is always a “surface” with which our users interact. This piece of the puzzle addresses the thousands of micro-design decisions necessary to communicate the Quality Attributes and embrace the discovered use patterns.

Typically an Architecture has a “style guide”, specifications, standardized controls and prototypes that define the boundaries of the solution space so that multiple designs over time reflect a coherence with an underlying structure. This puzzle piece covers all of the vocabularies (visual, interactive, architectural, content) we will use in our design.

Consider the rodent trap example. The aesthetic choices for the trap itself, the material, its packaging and the supporting marketing communication are all specified in this puzzle piece in support of the use models and Quality Attributes defined in the other pieces.

Most of the remaining deliverables in the Treasure Map fall into this area: in addition to Design Patterns, Style Guides and Specifications, I would include Concept Designs and Prototypes.

Design Principles

A design is part of an Architecture by virtue of its conformance with the underlying (or overarching) design principles laid out in the Architecture. Through a self-conscious, intentional choice of principles, the architect establishes a framework tying the other pieces together.

Design Principles are perhaps the most important ingredient to an Architecture; without them we would still have a design, or an engineering solution, but we wouldn’t know whether our design was part of a larger constellation of designs belonging to a common architecture.

According to Bill Buxton, one process distinguishing design from engineering is the formal nature of “critique.” Architects critique another’s work by reflecting on the Design Principles inherent in the solution. Either the work is criticized because of the (poor or inappropriate) choice of principles, or it is critiqued because it fails to conform to the explicitly chosen principles. In any event, designs can only be evaluated in the context of their Design Principles.

There are literally hundreds, if not thousands, of design principles. It is up to the Architect to decide which principles are key and which can be ignored. The choice of principles depends on several factors perhaps most critically, the subjective aesthetic of the Architect. When you decide to hire an architect, choose carefully - her design “aesthetic” (which principles she holds dear) may conflict with yours.

In the Puzzle Piece framework, Design Principles must be consistent with the Design Language, Use Patterns and the Quality Attributes. That is, the Design Principles must inform these other puzzle pieces as well as be informed by them.

A few articles back I made passing reference to three Vitruvian principles: firmitatis utilitatis venustatis, translated roughly as strength, utility, and beauty in the context of “elegant” design. Vitruvius, a Roman Architect, engineer authored his famous “10 Books of Architecture” over 2000 years ago, and briefly mentions these three characteristics as inherent to any design. I put these design characteristics together into a single “Vitruvian Principle.” For me, the Vitruvian Principle is a key metric I use to evaluate a design proposal: Is it robust? Is it useful? Is it appealing?

Which principles the Architect chooses and their relevance to the targeted audience is one meta-decision to be made. A second is how many principles to abide by.

Mies van de Rohe, a mid-20th century pillar of German and American Modernism, is famous for his design principle “Less is More.” The absurd conclusion of this principle leads to it being the only principle. Minimalist designs, Google’s home page for example, are driven by this principle.
Sticking to a single design principle (assuming for the moment it’s even possible) drives a purity in the solution. Assuming the design team is successful in driving an expression of this principles, users will feel its impact.
A single principle for most non-trivial design problems is likely impossible. At best it leads to tedious results, at worst, broken. If one principle is not enough, what is the upper limit? Theoretically there is no upper limit - one of the joys of Architecture is juggling the number of design principles. For some Architects, dozens of principles come into play as justifications for specific design decisions. It comes down to an individual’s capacity for keeping multiple balls in the air.

I top out at about a dozen principles for the most complex problem spaces; beyond 12 my design solutions become diluted by too many competing influences. For less complex problems, a handful of principles is usually more than sufficient. But again, this is a subjective decision, completely integrated with the Architect’s aesthetic and competency.

Finally, to be an Architecture, the Design Principles must be chosen intentionally and before the design is complete. Some may be picked a priori because they are part of the Architect’s aesthetic; others may be brought into play as new information about the problem is revealed. But as a new principle is brought into the Architecture, all of the prior decisions must be reviewed in light of the newcomer. The coherence of an Architecture depends on the interplay between the meta-decisions (Design Principles) and all of the design decisions. We don’t get to pick and choose which principle applies to which aspect of the design and still call the solution an Architecture.

This last piece of the puzzle is extraordinarily self-conscious. It is the constant reflective activity of design, in this case not on the experience design, but rather on the design of the Architecture itself.

So that’s about it. I’ll finish up next month with some reflections on how to get started in crafting an architecture and how you know you’re done.