Stage Directions Meet Functional Specifications: They Have a Lot in Common

Making the Metaphor: The Communication Convention Driving Guidelines for Implementation

The simple convention of stage directions lets playwrights address the directors and actors who undertake a production without their being physically present and without altering or interrupting the actual dialogue. This convention ensures the audience sees what the playwright intended. Upon reflection, the correlation between stage directions and the documentation of functionality seems pretty apparent and relevant.

In the same way that stage directions convey the intentions of the playwright, functional specifications are meant to convey the intent of the UX designer. In modern design—like modern theater—the functionality alone can’t tell the whole story. The UX designer may not be there to handhold the development process and ensure the design gets implemented as intended. Metaphorically, stage directions can help tell the story the functions alone cannot. As Table 1 shows, it is not just function, but function plus interactions and emotional response that create an overall user experience.

Table 1—Connections between the value of stage directions and the gaps in documentation

Stage directions tell:	Documenting functions alone doesn’t tell:
What characters enter and leave a scene	How a user might enter or leave a particular part of a site or application
What characters do on stage	What a user might be able to do while there—that is not a click
How characters do and say things	What the particular interaction is with some functionality
What happens in the background	What happens in the background
What sounds are heard	What audio cues help explain the functionality
What the lighting should be	What visual cues help explain the functionality
What the context is—the mood and environment	What the context is—helping set the conditions for the experience and the desired response
What the tempo and rhythm are	What the tempo and rhythm of the interaction or experience is
Stage Directions + Dialogue + Set = Overall Experience	Functions + Interactions + Emotional Response = Overall Experience

While contemplating the parallels between stage directions and functional specifications, I recognized two categories of requirements that, in my mind, traditional functional specifications do not address adequately: interactions—the specific behaviors of a user interface that achieve a function—and emotional or experience requirements—how a user should feel about experiencing the function. As an experiment, I decided to explore how they could be documented by using some form of stage directions. The Web site Searchme.com, shown in Figure 1, uses all the latest technology and provides a great experience, so I used it as my example.

When Defining Function Isn’t Enough to Convey the Interaction

We are quickly moving past a paradigm in which the only interaction you can achieve on a Web site is to click something and reload an entire page—opening up endless new opportunities for design. But it seems to me that our methods of documenting interactions have failed to keep up. There aren’t any good, standard ways of describing the intended interactions. A major source of the problem we’re encountering with these new technologies is that there is no longer only one way of technically achieving a specific function—especially if you are considering using Ajax or Flash technology.

So, when you have an idea for the way the interaction for a particular function should work that is more complex than click and reload the page, how do you document the interaction so it gets implemented as you intended? Have you found, as I did, that the static images of wireframes and accompanying text explaining the functionality don’t quite capture it all? If so, maybe you are ready to believe that, to create a design with the “spirit of life,” the user, the interactions, and the experience must become characters that speak for the design.

This gap in our documentation capabilities led me to explore the first category of requirements that lack standard documentation methods in depth: interaction requirements. I decided to examine and attempt to document a small piece of functionality on Searchme.com—the stacks that let you store sets of related search results—as though this were a new design that I needed to document for implementation. Here is my documentation for a very small subset of the functionality for stacks:

1 [Enter site]

2 Content Storage (Stacks)

2.1 Interaction Requirements: Upon arrival, stacks are in a default state of hidden. As the user mouses over the label stacks, the text color changes to indicate a change in state.

2.2 Function: View Stacks

2.2.1 Interaction Requirements: As the user clicks the label stacks, the text color changes to another color—different from that for mousing over—to indicate state. As this happens, a box appears and expands to show an icon and label for a new stack, plus the actions view, share, add URL, delete, and new—or an existing stack if there is one, with the system pulling in information in the background.

The primary stack animates as it appears. Another panel with a blank icon and a label for a new stack also appears. Once the animation is complete, the label hide stacks appears at the bottom.

What I realized in doing this exercise is that there are a number of interactions that occur before and during the one function of viewing the stacks. Just as Williams wrote more than a page of stage directions introducing the story in Streetcar, there is much to explain about the interactions before the user takes any action.

I was amazed at the detail that was lost by documenting only the function—and dismayed when I thought about the ramifications. Reading my description of the function, a developer might implement the functionality as a boring drop down. This simple interaction would neither meet my expectations as a UX designer nor take advantage of the technology available on this site. As a consultant who hands over specifications to clients for implementation, I shudder to think about how leaving certain details up to the imagination of others could result in a drastically different implementation than intended.

Defining the Spirit of the Design

While documenting the interaction requirements definitely seemed to help, I had this niggling feeling that there was still something missing. It seemed that the intangible spirit of the design remained undefined.

Along with all the capabilities of the new technologies and the resulting opportunities for sophisticated interactions, there has also arisen a new focus on the user experience—the emotional response that results from an interaction. While the premeditated design of the user experience wasn’t always thought about in the past, it is now becoming a requirement of good design to consider the kind of experience you are creating.

So, how do we communicate these intangibles that are no longer just an inherent, but an explicit part of the design? It isn’t the function or the interaction, but somehow may be a larger factor than those two together. As I looked at Searchme.com and thought about the implicit experience, where relevant, I added another level of emotional / experience requirements to the functions and interaction requirements, as documented in the following specifications:

1 [Enter site]

2 Content Storage (Stacks)

2.1 Interaction Requirements: Upon arrival, stacks are in a default state of hidden. As the user mouses over the label stacks, the text color changes to indicate a change in state.

2.2 Emotional / Experience Requirements: The minimal use of color helps direct a user’s eyes to this activity and gives clear indicators of state. Guidance and instructions are conveyed though icons and movement. Use of other explanatory text or icons would distract from the focus. This user interface should be intuitive enough not to need instructions. The user is shown the details of any section only when a particular function is in focus—that is, when a user mouses over it—and is not distracted with the details when focused elsewhere. When the user moves the focus elsewhere, the previously selected function collapses into a minimized view.

2.3 Function: View Stacks

2.3.1 Interaction Requirements: As the user clicks the label stacks, the text color changes to another color—different from that for mousing over—to indicate state. As this happens, a box appears and expands to show an icon and label for a new stack, plus the actions view, share, add URL, delete, and new—or an existing stack if there is one, with the system pulling in information in the background.

The primary stack animates as it appears. Another panel with a blank icon and a label for a new stack also appears. Once the animation is complete, the label hide stacks appears at the bottom.

2.3.2 Emotional/Experience Requirements: The Stack is unobtrusive and shows all functions only when the user mouses over it. The animations on mouse over are subtle and smooth.

Now, while I didn’t design this Web application, it’s pretty apparent that its designers put some serious thought into the experience they were creating and took care to make sure the design was implemented. Even lacking time and presence, the level of specifications I’ve provided would let me set some guidelines that would help drive the technical implementation in the right direction to achieve the desired response. It also achieves this without dictating anything about the underlying functionality or the technical implementation. (I like to think I’m not as much of a control freak as some call Williams.)

The Clever Trick Is Merely the Efficient Use of a Simple Convention

My experiment led me to the conclusion that the stage directions metaphor could be a valuable tool in creating more useful documentation paradigms. The most important thing I gained from the exercise is an understanding of the difference between a design’s functions, interactions, and emotional requirements. We need to communicate all of these to provide a clear and articulate picture of our designs for user interfaces.

Understanding the role each type of specification plays is key to ensuring the implementation meets the designer’s intentions and expectations. Through stage directions, Williams’s plays successfully develop their appropriate framework and context, evoking the desired sensory response in their audience. There is no reason a UX designer can’t be as successful in expressing the framework, context, and experiential aspects of a user interface design by providing clear, explicit directions in the design documentation. 

References

Horowitz, Israel. Stage Directions and Spared. New York: Dramatists Play Service, 1998.

Williams, Tennessee. A Streetcar Named Desire. New York: New Directions Publishing Corporation, 2004