The Magazine of the Usability Professionals' Association
By Leo Frishberg
What does it mean to characterize an individual’s experience in relation to a specific context, artifact, or environment? Assuming it’s even possible to characterize an individual’s experience, is it possible (or even desirable) to reduce the totality of an individual’s experience to an abstract diagram on a page?
As a “bricks-and-mortar” architect, my training provides me with several architectural models: bubble diagrams, adjacency diagrams, site analyses, floor plans, details, perspective renderings, 3D fly-throughs, scale models, and so forth. I use these models to help shape the different experiences of the building—not just the formal shape of its massing (how the volume of its parts fit with its surroundings) as seen from the sidewalk, but perhaps the way light interacts with an individual’s movement through a sequence of spaces, or the view of a mountain range through a particular window.
In the high-tech world computer engineers think about “architecture” in terms of structures, layers, and dependencies as in Figure 1. To simplify complex systems, hardware and software architects use diagrams to focus on the functionality and relationships of system components.
Figure 1: Hardware and software architecture diagrams
Is such a diagrammatic approach available for user experience architects who want to do more than simply model user tasks?
Assuming such clean representations of user experiences are possible, what advantage would they provide? Can we distill our work down to these kinds of abstractions? If we can, do we risk losing some essential aspect of the experience itself? Do we risk impoverishing the end user’s experience by abstracting it to lines on a page?
Practices in both computer engineering and bricks-and-mortar architecture suggest that such abstractions do not create impoverished results: (bulleted list)
For the engineering audience, uncomfortable with the ambiguities of human-computer interaction, we must find a way to communicate the key elements of the experience architecture. These elements inform the hardware and software architects of the places that need to be sensitive to the experience architecture. This need is indisputable. It remains to be seen whether diagramming experiences as described in this article will achieve this goal; it is a work in progress.
An experience is an individual’s (persona’s) engagement in an environment (context) over time. (bulleted list)
Experience schematics are models of experiences gleaned from research with real users. An experience schematic is composed of one or more sets of experience boundaries—representations of a persona’s interactions within a context and at a moment in time.
Experience schematics may be a useful abstraction because they: (bulleted list)
Because they are abstractions, experience schematics cannot fully express
Figure 2: A single experience boundary
An experience boundary (such as shown in Figure 2) describes one interaction at a specific moment in time.
Three dimensions apply to experience boundaries to create experience schematics:
The following table articulates several arrangements of boundaries that describe relationships between two or more experiences and form an experience schematic.
Separate, contiguous experiences
Each experience is understood as distinct. While each could stand alone without dependence on the other, the two are perceived as being tightly bound to one another. Together, the two create a perceived third experience different from each alone.
The difference in size denotes the difference in user attention. The user pays far more attention to the experience denoted by the boundary on the right than on the left boundary, whether by choice or because the situation demands it
Separate, disconnected and related experiences
Each experience is understood as distinct—each could stand alone without affecting the other. When experienced together over time, the two are understood to be related: one may be derivative of the other or they may share a visual design language, for example. Both boundaries have the same saturation to denote this relation.
Separate, disconnected and unrelated experiences
Each experience is completely unrelated to the other. The two have no relationship to one another. Placement and use of different saturations denote the separation.
Separate, unrelated and joined experiences
Each experience is understood as distinct and has no relationship to the other except via a highly constrained third experience.
Separate, contained experiences
The outer experience defines and constrains the contained experience. The contained experience is completely dependent on the outer experience in its expression, context, and the other experiences with which it is associated.
Integrated, contained experiences
The contained experience is only barely distinguished from the outer experience—it shares virtually all elements of the outer experience, but is differentiated in only one or, at most, two ways. The specific boundary condition may not be clearly perceptible and may change over time or under different conditions. The core of the contained experience is distinguishable from the core of the outer experience.
While other relationships can be imagined, the basic elements in the table suffice to describe a rich set of experiences, desired and undesired.
When I use experience schematics to model a persona’s experiences, I create two diagrams:
The context of human computer interaction extends beyond the screen—so too experience schematics. They apply to any human experience the designer wishes to model.
Consider, after appropriate study of a target population’s behaviors, modeling a set of experiences around preparing breakfast in the morning, as in Figure 3.
Figure 3: An experience schematic
Imagine this schematic is a generic summary of observations of several individuals for whom I was commissioned to design a new breakfast experience. Since experiences occur over time, this snapshot might never be observed in one coherent moment. Perhaps the experience from starting breakfast to completing it would require several schematics, each shifting slightly like a cel in an animation (Figure 4).
Figure 4: A set of experiences
After additional analysis of the observations, perhaps multiple personas would appear. For each, a different set of schematics would model the desired experiences (Figure 5).
Figure 5: Experience schematic variant for a specific persona
For this persona, the newspaper reading experience is much more tightly bound into the eating experience, and this persona doesn’t prepare breakfast or clean up.
Because experiences change over time, you could imagine boundaries shifting as different elements of the breakfast preparation experience develop. Creating a stream of shifting boundaries helps visualize the flow of the persona’s experience (Figure 6).
Figure 6: Experience flow
While many of us believe time flows linearly, experiences may be revisited. Rather than repeat a schematic, the blue arrows in Figure 6 might circle back to a previous state.
Experience schematics are abstractions of persona experiences. Use them to diagram key experiences distinguishing one persona’s experience from another.
In Cooper’s design process (www.cooper.com), context scenarios describe a persona’s optimal interactions with the designed experience. The key experience is that which best distinguishes one persona’s experience from another, analogous to a key frame in a video stream.
Let’s assume my examples model a hotel breakfast. In the first experience, the guest prepares breakfast, perhaps at a breakfast buffet, or in the hotel room. In the second experience, the guest is served breakfast by a waiter.
Part of the design commission is about delivering a better news-reading experience. Figure 7 illustrates the key experiences for two personas.
Figure 7: Two personas’ news-reading key experience
Seeing each persona’s distribution of attention, their distinctions among the various experiences, and the relationship of each experience to the others helps in two ways:
I’m still working through the novelty of this approach, both for my own work and with my team. When members of my engineering teams look at these diagrams, they immediately assume I’m referring to user interface screens—their experience with UX professionals to date has focused mostly on UI design. I need to take a few moments to explain that the diagrams reflect the userexperience, not the user interface for a particular software application.
Others have questioned whether these blocks represent process diagrams in which the geographical location of a block implies a chronological sequence. Except in the case of experience flows, I consider each of these diagrams a cel in an animation: the diagrams reflect a moment in time rather than a time flow. My intention for the blocks is more to show relative amounts of attention, dependencies, and relationships among the experiences, both for a specific persona and across personas.
Others have misinterpreted these diagrams as representing activities or tasks rather than experiences. Creating task diagrams of specific parts of an experience captured by an experience boundary (and similarly, creating highly structured UML representations of activities occurring within a boundary), is appropriate at a more detailed design level, but it isn’t my purpose at this level of abstraction.
From an experiential design perspective and, more critically, from a user-experience architecture perspective, the point is not to model the exact interactions going on in the experience. Rather, we aim to identify the key moments during a stream of experience to focus our design efforts around, and with luck, to impart to our users our desired, designed sensibility.
Although still a work in progress, experience boundaries and schematics are providing me with one more tool for visualizing my personas’ key experiences. In addition, they provide a recognizable format for communicating my overarching design framework to my team of engineers, designers, managers, and marketers.
Leo Frishberg is principal architect, user experience for Tektronix, Inc.'s Logic Analyzer Advanced Development Group. For over twenty years his professional life has focused on enhancing the user experience with architectural, software, hardware, and web projects. For the past six years he has served as both program chair and executive director for CHIFOO (Computer Human Interaction Forum of Oregon), the Portland-based local chapter of the SIGCHI. He is a licensed architect, with an M.Arch from SCI-ARC and a BA in Environmental Planning from University of California, Santa Cruz.
Usability Professionals' Association
promoting usability concepts and techniques worldwide
User Experience Magazine is by and about usability professionals, featuring significant and unique articles dealing with the broad field of usability and the user experience.
This article was originally printed in User Experience Magazine, Volume 7, Issue 2, 2008.
© Usability Professionals' Association
Contact UPA at http://www.usabilityprofessionals.org/about_upa/contact_upa.html