Tutorials

This tutorial provides hands-experience in developing stories. We cover the history, composition, relationship to other methods, how to develop and maintain a story, and how stories fit into the development process. The bulk of the time is spent building stories and discussing lessons learned.

PARTICIPANT KNOWLEDGE AND EXPERIENCE EXPECTED

Learning Objectives:

In this tutorial, a repeat of a well-received tutorial from UPA 2002, we demonstrate a story-based approach to describing users, the tasks they perform, and the environment they work in, and distinguish this approach from other related approaches. While we will compare and contrast stories to other constructs such as personas and use cases, these will not be covered in depth, nor will they be part of the hands-on exercises. Also referred to by some (e.g., Carroll) as scenario-based design, we provide hands-on experience in using the story-based approach via multiple break-out sessions/exercises. Participants will also share as many tips and techniques as possible for incorporating this method into the design and development process. Participants should already have a grounding in basic ethnographic methods as we will not be teaching those in this session.

GOALS FOR THE SESSION:

Participants in this tutorial will:

• Gain direct experience of the value of collecting user stories.
• Learn to collect and validate stories. Attendees will observe and interview hotel employees, and learn to integrate ethnographic research into story development.
• Learn to incorporate stories into the design process. Attendees will discuss abstracting traditional usability design tools (lower-level scenarios, storyboards, use cases, and personas) from stories. Attendees will discuss the importance of stories for maintaining the context of their abstractions throughout the development cycle.
• Understand trade-offs in various methods of developing stories. We will compare stories and scenarios built with user data to stories and scenarios based on expert analysis. As exercises, attendees will build both types of stories and make their own evaluations of accuracy and fidelity of both methods. Attendees will discuss in depth the validation issues associated with stories, regardless of source or methodology.
• Learn from the instructors and others in the group about their experiences, including tips and pitfalls to avoid.

We will begin with an introduction and overview of story-based design. We will talk generally about doing user research and collecting stories as a part of the overall design process, noting where exceptions and “shortcuts” can occur and why. We will talk about why we believe that user stories are important throughout the design process and what makes a compelling story for the rest of the team, again using case studies as a guide. We will then move into our hands-on learning experience, consisting of 2 exercises. Finally, we will end with discussions about putting this method into use and integrating it into the design and development process.

HOW THIS TUTORIAL WILL BE CONDUCTED

This tutorial balances presentation, small group exercises, and discussion. We will use slides to cover presentation materials. There are exercise guides, information collection, and story generation materials we will provide the participants, during the course of the tutorial. Additionally, a bibliography and discussion question guide are included in the tutorial materials.

We will begin with an introduction and overview of story-based design. We will talk generally about doing user research and collecting stories as a part of the overall design process, noting where exceptions and “shortcuts” can occur and why. We will talk about why we believe that user stories are important throughout the design process and what makes a compelling story for the rest of the team, again using case studies as a guide. We will then move into our hands-on learning experience, consisting of 2 exercises. Finally, we will end with discussions about putting this method into use and integrating it into the design and development process.

TUTORIAL SCHEDULE WITH TIME ALLOCATION

DETAILED DESCRIPTION OF TUTORIAL

Introduction and Description

Many usability professionals learn methods and techniques by reading books and articles on the topics. Many of us have wondered where the various tools can fit together, where shortcuts can be taken, and what we need to watch out for if we do that. There are several very similar, or related approaches to story-based design, e.g., scenario-based design, contextual design, and usage-centered design. Story-based design supplements those approaches with a slightly different set of deliverables using a narrative story structure to make user data more accessible across the many disciplines and backgrounds of a typical development team.

To design a system that provides real value to users and also delights them, all members of the design and development team need to understand the people for whom they are designing, their goals, their environment, their interactions, and their tasks. Stories capture this understanding in a rich and meaningful way that does not predispose any particular implementation, but which is in a form that all the members of the design and development team can relate to and use throughout the process. By getting this agreement up front, the team has a common vision of the users and their world, based on observed user behaviors and validated by users, instead of relying on professional opinion.

The incorporation of user “goals” in this method is critical, because many techniques focus on understanding either what the system can do, or what users currently do, and not necessarily on what they want or need to do.

Overview of Stories

This tutorial teaches stories as a core method of recording and disseminating information about users. This sample story below illustrates how we use stories to integrate user, task, and environment information, and is one of the examples that will be used in the tutorial. This explicit integration, without the specific product implementation, is the key difference between story-based design and using personas, user descriptions, scenarios and the like.

Example story:

Located in one of the upper floors of the bank's IT headquarters is the system administration section. The folks that work here are responsible for keeping the Information Technology infrastructure running. A lost minute means thousands of dollars lost and potential for losing customers and severe penalties. The bank clears checks totaling $100million/day, so a disruption of this system is especially painful for the bank and its customers. ß Here we set the stage with some description of the overall environment.

Bill, 43, is a software distributor working for the IT System group in a large global bank. He has been with the bank for ten years, working up from the operations center to his current position. Given the structure of the organization, Bill has risen about as far as he can expect to, unless he shifts to another aspect of the bank and into management. He has thought about it, but prefers technical to management challenges, so decided to stay where he is. He likes the fact that when he leaves work, he no longer has to think about it. Instead he can concentrate on his family and his new hobby: pottery. He is thinking about setting up a small side business selling what he makes. He has been trained on setting up software distributions, but is shaky on networking troubleshooting and sometimes is daunted by the size of the enterprise he helps administer. ß Here is the basis for the primary actor and has the information typical of a persona.

Generally speaking his job is to distribute software packages across functions at the bank. This can mean sending new versions of software out to the banks' employees (i.e., a new version of Office) or patches to existing versions of software when the software companies publish them. Usually these kinds of distributions can take place during the day with no disruption to banking operations. However, in this case, the software being distributed is a large core-business application and needs to be distributed after normal banking hours, when the check processing system can be shut down for 4 hours. ß Here is some high-level task information and environment information is blended.

Everyone expects this to be a routine distribution. However, at 2am on Monday morning, toward the end of the distribution, Bill finds himself staring at a flashing error message that is outside the scope of his knowledge and experience. He clicks on the help button, but it's no help. He goes to the online help for the distribution tool, and discovers that they do not publish the error codes online. He realizes that it might not be a problem with that software, but with some of the network software. Since Bill is not a network specialist, he's really in over his head. ß Here we integrate some more actor information with task information.

Bill knows that if Jack were here, this would be no problem because Jack is the team's source of obscure bits of technical trivia. Jack always knows the right person to call. Bill rushes to Jack's cubicle to rummage through Jack's sticky notes, stacks of technical documentation, company procedures, contact numbers, and shelves of bound manuals. He calls some of the contact numbers, but no one answers. One of the contact numbers is no longer valid; the rest are not answered. If only the information he needed had been placed where Bill could find it easily. He finally calls security to have them unlock Jack's desk to see if there are any more up-to-date clues on what do to, which wastes an additional 45 minutes. After two hours of searching, Bill gives up. Nothing there seems obviously applicable. He faces the cold fact that in three hours his management will be there, and there is no time left to complete the distribution. Bill's only hope is to get the old version of the software running in time for the check processing system to be up by the start of the day… ß Here we integrate additional task information with more persona and environment information.

As you can tell from the annotations in the example story above, this method uses much of the same information that traditional design methods use. The difference is in the integration of the information into a single, integrated document. The other methods rely on the user of the documents to do the integration. This increases the probability of miscommunication and other errors due to differences in individual frames of reference. By integrating the information the frame of reference is set or at least narrowed. The more detailed the story the narrower the range of interpretations.

This tutorial will provide the participants with practical experience in developing stories using two different methods, and demonstrates the impact of gathering user information first or developing the stories first. This tutorial uses field techniques of having the participants observe and interview real users in a field setting, using hotel and conference staff as “users/customers”. We have found that some practitioners develop the stories or scenarios in the abstract, without talking to real users, and, while this may be acceptable in some circumstances with enough background and proper validation, it is not always the case. This tutorial will let the participants experience both methods: the “constructed” stories and the composite stories obtained by gathering information from real people in real task situations and then building stories based on anecdotes and/or combined descriptions. In this way, the participants will get first-hand experience with both approaches and will get to see for themselves what works and what doesn't based on this experience and on the experiences related by the instructors from their own case studies.

Schedule Details:

Introduction to tutorial, instructors, and goals (Presentation and discussion, 20 minutes)

Describe process, methods, techniques (Presentation, 70 minutes)

First, we will provide some background on story-based design, and the similarities and differences between that and other related methods. As mentioned briefly above, our basic philosophy of design integrates the descriptive information into a single document. The story-based philosophy of design puts primary importance on describing the inter-relationships and interactions of the user with his or her tasks, environment, and goals. Other design philosophies make use of these same components (users, tasks, environment, and goals) but often emphasize one or another of these components above the others, or, focus on the system itself and not the user. For example, business process re-engineering emphasizes the tasks and procedures, and technology-based design has the capabilities of the tools shaping the design interaction. Another example is the use of user descriptions. A variable in a user description may be experience, with values from 0 to 20 years, a mean of 6 years, and a median of 7 years. Contrast that with personas that might pick several key experience points and build a persona around those, or concentrate on other characteristics if they were more salient to portraying user differences. In story-based design, all the parts are looked at, analyzed, described, and used in a holistic solution, and, in the end, may result in a design that involves changes in business processes, tools, tasks, or interfaces.

A story-based process uses narrative techniques that can be used to envision possible solutions. Users or personas become the main characters in a narrative that describes how they would use the product. Exploring situations in scenarios that follow identifies functional needs that arise from the user's or persona's goals. What is important to note is that story-based design does not assume any one particular design methodology, and indeed, fits well into many of them. For example, Constantine and Lockwood's “usage-centered design” is quite compatible with Rosson and Carrol's “scenario-driven design” and with story-based design. All three of these are focused on what the users are trying to accomplish, and then developing design solutions to meet those needs.

Next, we will cover the process of collecting or building the stories themselves. There are two approaches to this process, each of which has their advantages and disadvantages. The first we'll call “fictional” stories, which are those stories created by the design team based on their understanding of the users and their goals. Fictional stories can, and should, be based on research on the intended users, and may be particularly useful for design solutions in a space that does not yet exist, and thus the users would not be very likely to be able to generate the stories themselves. The second type we'll call “customer” stories, which are those stories based on customer experiences. This type of story also breaks down into two sub-types: those that are actual anecdotes from users, and those that are extrapolated across multiple users, which Erickson would call “design stories”. The caution for anything created regardless of method, however, is to make sure it is validated before proceeding further.

In both of these general approaches to stories, however, there are still four basic tasks: (1) gathering the data, (2) analyzing the data, (3) assembling the stories, and (4) validating and updating the stories. In this tutorial, we will cover most of this approach in our hands-on exercises. Because we learn best by doing, about half of the tutorial will encompass going through the process together with a sample problem. In our discussions following the exercises, we will cover such topics as:

• The costs and benefits of two different approaches to user research
• Practical recommendations for conducting user research
• The most relevant aspects of user behavior and communication to gather “nuggets” for input into innovative solution design
• Why it's important not to skimp on this step of the process
• When they might be able to take shortcuts under tight deadlines and budgets, but also what the tradeoffs are
• How to bring stories into the storyboards and use them to translate the stories into design solutions that work
• How to involve users as effective design partners so we can understand what they really want and how to meet their needs.  

Exercise 1 preparation and instructions (Presentation, 15 minutes)

The exercises will involve groups of 3-6 attendees working together. The design problem we will be using for this session is how to improve customer satisfaction with the hotel stay. Various user groups from the conference hotel will be visited (with prior arrangement), e.g., front desk, reservations, housekeeping, and the bellmen. For Exercise 1, half the attendees from each table will construct user descriptions and personas and then outline stories based on the problem statement information they are given. The other half of the attendees from each table will be assigned to a user group for their “site visit” where they will observe and interview the users of the system – the hotel staff. From this exercise they will be gathering stories from the users and collecting information to be doing some story consolidation and construction as well.

Exercise 1 (Small groups, 60 minutes)

½ of participants do field work; ½ of participants do story construction

Exercise I debrief (Discussion, 30 minutes)

We will discuss the similarities and differences in the approaches to story-construction, as well as attendee's experiences in doing the exercises. We will discuss the pros and cons of the approaches and related them to our own case studies and lessons learned.

Exercise II prep and instructions (Presentation, 15 minutes)

In Exercise 2, the group that gathered data in Exercise 1 will construct their story and story elements as a group; the group that constructed a story and story elements will validate those with the hotel staff

Exercise 2 (Small groups, 45 minutes)

½ of participants do story construction; ½ of participants do field work (switch from Exercise 1)

Story Completion (30 minutes, small groups)

During this period the groups will complete their stories and story elements. This will provide each group with a chance to fill in information they missed and perform any validation they feel necessary.

Debrief, General discussion, Process integration, and wrap up (Discussion, 90 minutes)

First the group that gathered data in exercise 1 will present the results of their exercise, then the group that created a story in exercise 1 will present their results. Following this we will compare their experiences and results.

Following the discussion of the exercises, we'll discuss the strengths and limitations of this approach, we will discuss the lessons the instructors have learned applying these techniques in design. These form the basis for making decisions about how to apply the various design methods. For example:

• Stories are an effective way for conveying to diverse groups a rich picture of whom the user is and what they are trying to do.
• Each method has limitations. By counterbalancing them and using multiple methods, you can minimize the risks.
• Beware of edge cases. Set the range of users that are your primary group and thoroughly define them.
• Build personas based on carefully selected characteristics from your user group. Cover the range of central characteristics. They won't necessarily equate to a real person. Beware of them becoming edge cases.
• The stories are more than just personas. The task and environment are also important and need to be well researched and described.
• While we can all build stories, some training and practice are key. Observation and interview skills are crucial for gathering the information. Integration skills are needed to build the story from the data and story telling skills help build a compelling story.

The instructors will then end the day by facilitating a discussion in which participants can share how they might begin implementing the material covered throughout the tutorial.

SPEAKER BIOS

Gary Macomber

Consultant

HumanCentric Design

Gary has worked in a wide variety of positions defining requirements and evaluating systems usability as well as building prototypes. He has validated product and UI direction as well as evaluated UI fit in a wide variety of product solutions. He has used structured analysis, storyboarding, and stories as critical components of defining and communicating user actions and expectations.

Gary is a member BayCHI and is an active member of the Usability Professionals' Association and its local Austin chapter. He is serving on the UPA board of directors as Web Director and serves as web co-chair of the annual conference. He has a Ph.D. in Industrial and Systems Engineering from Virginia Tech University.

Thyra Rauch

Customer Research Architect

IBM

Thyra, who has worked at IBM for seventeen years, currently is on the Data Management team working on information integration solutions. She has been instrumental in validating product and UI direction, user roles, and role/task pairings across a number of different industries for multiple product solutions. She has been using customer stories and storyboarding as an integral part of her design process.

Thyra is an active member of the Usability Professionals' Association and is currently serving a second term on its board of directors as Secretary/Treasurer. She has a Ph.D. in experimental psychology from North Carolina State University, and is the author of 10 patents relating to user interface design.