Читать книгу Storytelling for User Experience - Kevin Brooks - Страница 7

Оглавление

Chapter 5

Stories as Part of a UX Process

Using stories in user experience design is not a new idea

Stories can be part of many UX activities

Now that we’ve explored what a story is, the ethics of telling them, and how stories empower people through listening, it’s time to think about how all of this fits into user experience design.

If you are looking for inspiration at a specific point in a project, the chapters in this section each focus on one aspect of user experience design, in a roughly chronological order.

We are not going to promote one approach to user experience design over another, nor are we going to promote a new methodology based on using stories. Whether you believe in user-centered design, goals-based design, or even a more technical approach like domain-driven design, stories have a place in your work.

Despite the number of approaches to user experience design, the core is usually quite simple, so we will stick to this generic process: start by understanding the context, put that understanding to work in creating the design, and then test the design as it is fleshed out to be sure that the product will be a good fit.

There’s even an international standard that describes this generic process—the “human-centered design process for interactive systems.” Its official name is ISO 13407, but it’s being updated as ISO 9241-210 to broaden its scope from usability to user experience. Figure 5.1 shows a simplified diagram of the stages of the process.

Figure 5.1 http://www.flickr.com/photos/rosenfeldmedia/4459197715/

A model of a human-centered design process.

It starts with planning, working within a process—any process—that provides a structure for your work. It doesn’t have to be a rigid plan (although some of you may work within a highly structured product lifecycle). But if you don’t plan time for user experience work, or make room for understanding users within your methodology, it just won’t happen.

The rest of this process is a cycle of activities through which you will build and test your design:

Understand (conduct user research and investigate the context of use)

Specify (analyze the business and user research to define what the product will do)

Design (create the actual product design, from early sketches to final designs)

Evaluate (check the designs to be sure they meet the goals for the product)

There are three important features of this process.

First, it’s iterative. Ideas can be tested and either accepted or discarded. Designs can be created and tested until a good solution is found. This also allows a user experience design team to start with rough sketches or wireframes and build them into a finished design, testing at each stage.

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 http://www.flickr.com/photos/rosenfeldmedia/4459977926/

You collect input from many sources.

You are probably already hearing these stories. All you have to do is make a conscious effort to recognize them as stories and collect them. You can also make a note of what pieces of the stories might be missing that you can fill in later with additional research.

In the human-centered design process, this is part of the understanding stage. Your story focus in this stage is to listen for stories that provide an interesting experience, viewpoint, or way of describing an experience.

When you are exploring user research and other information

The stories you collect complement other data, from site logs to functional analysis. They can provide explanations for what surveys, usage analysis, or other data are telling you, or point to places where you need more information. During your analysis, you can select the stories that illuminate the data, as shown in Figure 5.3.

Figure 5.3 http://www.flickr.com/photos/rosenfeldmedia/4459978018/

Stories illuminate data during analysis.

Although the user research team is still the primary audience for these stories, you are already thinking about which stories and which story images will resonate with designers, developers, managers, or anyone else who may rely on your work.

In the human-centered design process, this is part of both understanding and specifying, as you transform your first understanding into a view of the needs that the project must meet. Your story focus in this stage is to select the stories that are compelling examples, those which illustrate patterns and personas.

When you experiment with design ideas

Stories are raw material for design innovation. Story fragments can stimulate new ideas. Stories from the field can describe problems to solve or scenarios of how things might be improved. They can help you explore new ideas or test an early draft of a design (see Figure 5.4). Because stories focus on people and their motivations, they can help realign a drifting or divergent design process back toward the people who will use the product.

Figure 5.4 http://www.flickr.com/photos/rosenfeldmedia/4459197943/

Stories can lead to design ideas.

In this stage, your audience begins to grow. The stories you create are valuable to the user experience team, but also must be credible to the full product team.

As you and your colleagues become accustomed to using stories, you will find that you have a wider choice of story formats and more ways to use them.

In the human-centered design process, this is part of the design stage, as you start to envision a new design and user experience. Your story focus in this stage is about using stories to help generate ideas and keep the emerging design grounded in real user needs. You can also create new stories that show the design in context and action.

When you want to test your designs

Stories even have a function in evaluation (see Figure 5.5). They can give you a scenario to kick off a task or define what you want participants to do during the test.

Figure 5.5 http://www.flickr.com/photos/rosenfeldmedia/4459978224/

Stories make good scenarios for testing tasks.

Going back to these original stories will ensure that the new product has stayed true to your user needs and initial inspiration.

In the human-centered design process, this is part of the evaluation stage, as a check that the design works as intended for real people. Your story focus in this stage is on reusing and adapting your stories to be suitable as test scenarios.

When you need to share (or sell) yourideas

We may like to think that a great design or a great idea will sell itself, but if a picture is worth a thousand words, a story can be just the right number of words needed to explain what that picture (or design prototype) is all about. Stories become part of the connections between the user research and design (see Figure 5.6). They can explain why a design will work because they connect the design with the inspiration for the designer’s idea.

Figure 5.6 http://www.flickr.com/photos/rosenfeldmedia/4459198105/

The team can share ideas by sharing stories.