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

By Traci Lepore

Published: March 9, 2009

“Whether they establish a production’s overall tone or elucidate particular actions of characters, stage directions help tell the complete story that is in the playwright’s mind.”

When it comes to modern theater, stage directions—the descriptive text that appears within brackets in a script—are an important piece of the puzzle. They speak for the playwright when he is not there. They provide details about how the playwright has imagined the environment and atmosphere. They describe critical physical aspects of the characters and settings. Stage directions can also be critical in dictating the intended tempo and rhythm of the piece. Whether they establish a production’s overall tone or elucidate particular actions of characters, stage directions help tell the complete story that is in the playwright’s mind. Stage directions accomplish all of this, using a simple convention that structurally separates them from the actual story.

Tennessee Williams, the playwright of A Streetcar Named Desire, strives to give a play “the spirit of life” through his stage directions. Read the following snippet from the opening of Scene 1, and you’ll find it’s hard to argue that he doesn’t achieve that goal.

From A Streetcar Named Desire, Scene 1:

[Two men come around the corner, Stanley Kowalski and Mitch. They are about twenty eight or thirty years old, roughly dressed in denim work clothes. Stanley carries his bowling jacket and a red-stained package from a butcher’s. They stop at the foot of the steps.]

Stanley [bellowing]: Hey, there! Stella, baby!

[Stella comes out on the first floor landing, a gentle young woman, about twenty-five, and of a background obviously quite different from her husband’s.]

Stella [mildly]: Don’t holler at me like that. Hi, Mitch.

Stanley: Catch!

Stella: What?

Stanley: Meat!

[He heaves the package at her. She cries out in protest but manages to catch it; then she laughs breathlessly. Her husband and his companion have already started back around the corner.]

Williams’s stage directions paint quite a picture—a clear and articulate physical and emotional setting for his characters. Just from his stage directions, we already know quite a lot about Stanley and Stella and the dynamics of their relationship
—boorish macho man and the ladylike, genteel wife. Before the play’s first word is even spoken, Williams has vividly drawn the setting for us in Streetcar and introduced his story’s themes. If we were to erase Tennessee Williams’s stage directions from the Streetcar scene, it would be emotionally flat and missing crucial details that illuminate the characters and themes of the overall story.

“A combination of the ever-increasing popularity and adoption of Web 2.0 technology and the movement toward user-centered design philosophies…is making documenting Web-application functionality a challenging and sometimes downright impossible task.”

Williams is famous for his explicit and detailed stage directions. He is a master many both praise and criticize for his preciseness. I believe UX designers can learn a lot from him.

One of the most interesting scripts I have worked with is a short play by Israel Horowitz called Stage Directions. The entire piece, in fact, comprises stage directions, with no dialogue at all. Yet it manages to communicate more about its characters and their emotions than most plays I’ve read—in this case, two sisters and a brother together after their parents’ funeral.

A combination of the ever-increasing popularity and adoption of Web 2.0 technology and the movement toward user-centered design philosophies—a UX designer’s dream—is making documenting Web-application functionality a challenging and sometimes downright impossible task—a nightmare using some standard methods.

As I recently struggled to figure out some logical way of documenting advanced interactions clearly using my company’s own documentation format, I pondered new possibilities for the documentation of interactivity. When the idea of using stage directions as an analogy bubbled up to the top of my mind, I excitedly started thinking about great examples of stage directions in plays I’ve read, and Tennessee Williams seemed like an appropriate source in this world of true experience design. So off I went, digging a little deeper to learn more about this simple convention and what makes it work so well.

Making the Metaphor: The Communication Convention Driving Guidelines for Implementation

“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.”

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.

Figure 1—Searchme.com

Searchme.com

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

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.

Stacks

Stacks on hover

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.

Expanded stacks

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

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.

Stacks

Stacks on hover

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.

Expanded stacks

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

“The stage directions metaphor could be a valuable tool in creating more useful documentation paradigms.”

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

Join the Discussion

Asterisks (*) indicate required information.