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?

Architectural Diagrams

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.

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:

• Engineering systems, complex beyond comprehension, are distilled to straightforward descriptions. Engineers focus on local complexities-of-interest, letting the remainder of the system become background.
• Architects manipulate sketches and models of complex built environments to help reduce risks of misrepresenting the final result

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.

Experience Schematics

An experience is an individual’s (persona’s) engagement in an environment (context) over time.

• Experiences depend on the individual’s subjective perception of the context.
• Time may mean mere moments or a span of years.

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:

• Describe large-scale, high-level views of the relationships of various activities to one another
• Permit evaluation of specific designs by helping the design team determine whether proposed interactions fit the desired experience relationships
• Provide more general expressions of the user experience than can be provided by specific key scenarios or storyboards
• Provide the engineering teams with a familiar method of expressing architectural issues

Because they are abstractions, experience schematics cannot fully express

• The richness of a proposed experience—a context makes them meaningful
• The flow of an experience—they are instead snapshots or key frames

Experience Boundaries

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 relative size of an experience boundary indicates the relative amount of the persona’s attention paid to the experience.
• The distance between boundaries implies the degree of user-effort required to integrate the two experiences.
• The saturation of the boundary’s fill-color suggests the degree of disparity between two or more experiences.

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.

Example

When I use experience schematics to model a persona’s experiences, I create two diagrams:

• The key experiences for each persona
• The key experience flow for the persona

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.

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).

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).

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.

Experience Flows

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).

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.

Key Experiences

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.

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:

• We can visualize the key differences between these personas that may inform our design solutions.
• We can communicate to the engineering teams these key differences in ways that they may be more likely to understand.

Practical Application

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 user experience, 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.