Storytelling for User Experience. Kevin Brooks

      Stories can iterate with the rest of the design. For example, they might start with a small anecdote and then get shaped into a complete scenario that illustrates a function. New stories can be found during evaluation that will help shape the next iteration of the design.

      Second, it’s scalable. Different parts of a product can be moved through this process at different times. An early version of a design might include only the most basic sketch of a feature, which will be designed in detail in a mini-process. Stories can also scale from short fragments to a more complete story as your understanding of the product grows.

      Finally, it applies to any type of project. Whether you are building an informational Web site, defining a taxonomy, creating a new electronic device, developing an online application, writing documentation, or designing a piece of furniture, this general cycle is useful for building, from understanding to evaluation.

      As you go through this process, stories help you keep people at the center of your work. This can be hard, especially when you do not have easy access to users. A good story can remind you of the real-world contexts in which your products will be used.

UX is a cross-disciplinary practice

      Although we’re not the first to say it, the vision for user experience design is for a cross-disciplinary practice, with everyone working on one team, bringing together all of the skills needed to create an excellent product. This vision is not universally achieved.

      We’ve seen everything from one-person UX teams to companies where the entire team (including designers and project managers and development staff and marketing and all of the UX disciplines) participated in the user research, analysis, and design. As William Gibson has famously said, “The future is already here. It’s just not very evenly distributed.”

      In whichever way your team is structured, when we talk about working with stories, we are not suggesting that this is a new specialty, requiring adding a “storyteller” or “story thinker” to the team. In fact, we hope that “story thinking” can help everyone be more creative, no matter what their roles are.

      When we talk about how “you” can collect stories, or how “you” can select stories to use as design inspiration, anyone on the team might be that person at any point in the process. Or it might be a group of “you” collaborating on one piece of a larger project.

Using stories in user experience design is not a new idea

      We are not the first people to notice that stories can be incorporated into user experience design. Many different approaches and methodologies use story forms as a way of communicating information about the user experience.

      Ethnography, one of the disciplines that is the basis for field methods in user research (that is, observing people and their behavior in context), also focuses on the human story and the ability of that story to communicate. AIGA’s An Ethnography Primer says that one role of the ethnographer is to “tell the story in a way that helps people embrace recommendations and create a shared vision.”

      Tom Erickson, an interaction designer and researcher for IBM (and before that, for Apple), uses stories throughout the design process. In his view, story gathering begins the design process, and stories are then used to communicate design requirements and user information to the development team. Prototypes based on stories allow the team to explore a new vision, especially one that is innovative, rather than a small improvement on a previous design. His essays on storytelling in design emphasize the value of stories as a way to stimulate design thinking and enhance communication among a design team.

      John Carroll and Mary Beth Rosson’s scenario-based design uses stories to ensure that user experience is included in software development. They recognize that scenarios are a way to communicate important information about the human-computer interface without writing technical specifications. Their scenarios describe the goals, behaviors, and experience of the people using the system.

      Sometimes, scenarios sound a lot like use cases, but use cases typically focus on describing all of the events in an interaction, including actions performed by the system (or “actors” within the computer system). They are intended to document the interaction that will be part of a program, rather than describe the environment and the broader user experience, too. In their “usage-centered design,” Larry Constantine and Lucy Lockwood use the basic format of use cases and other software models to define user goals and the features or activities that let people meet those goals.

      These stories are collected and then later filled out in conversations with users and other stakeholders. They are usually simple requirements in a format that describes the user role, the goal, and the reason for the goal. These stories are collected and then later filled out in conversations with users. However, agile development methods emphasize that the role of user stories is to capture testable requirements in a rapid, simple way. They are often no more than a single sentence. One of many good agile Web sites “Agile Software Development Made Easy!” (www.agile-software-development.com/2008/04/writing-good-user-stories.html) relates, “User Stories are a simple way of capturing user requirements throughout a project—an alternative to writing lengthy requirements specifications all up-front. The basic construct of an agile user story is, “As a [user role], I want to [goal], so I can [reason],” for example:

      As a job seeker, I want to search for a job, so I can advance my career.

      As a recruiter, I want to post a job vacancy, so I can find a new team member.

      JoAnne Hackos and Ginny Redish focused on scenarios and stories in their seminal book, User and Task Analysis for Interface Design. They traced scenarios through the process as a way of communicating analysis. Their understanding of scenarios was as broad as our view of stories and storytelling.

      “Scenarios can be about users, their work, their environments, how they do tasks, the tasks they need to do, and all combinations of these elements. Storytelling has the advantages of bringing people, places, and actions alive. It can also give you insights into the attributes of tasks you need to accommodate in your design, what users value, and what they see as aids and obstacles to accomplishing their goal.”

      —User and Task Analysis for Interface Design

      They identified several types of stories (or, as they call them, scenarios) from brief scenarios and vignettes, which provide a concise view of a situation, environment, or how a user currently does something, to elaborated task scenarios and use scenarios, narratives that describe an interaction from beginning to end. They suggested using these scenarios in several different ways. First, the brief scenarios are a way to collect insights. Task scenarios help document user, information, and interaction needs, while setting them in a context. Finally, use scenarios tell a story about the new design and how people will interact with it.

Stories can be part of many UX activities

      We’ll focus on five parts of the UX process where storytelling can be most useful, thinking about the audience for the stories in each:

       When you are collecting input

       When you are exploring user research and other information

       When you stimulate or experiment with design ideas

       When you want to test your designs

       When you need to share (or sell) your ideas

      When you are collecting input

      Anytime you work with users, you have a chance to listen for the stories they tell about their home or work lives, how they can work better, and what they want (see Figure 5.2). During this phase of the work, you (and your fellow user experience colleagues) are the primary audience for the stories because you are listening to stories from users and other stakeholders.

      Figure 5.2