Context scenarios should be broad and relatively shallow in scope. They should not describe product or interaction detail but rather should focus on high-level actions from the user’s perspective. It is important to map out the big picture first so that we can systematically identify user requirements. Only then will we be able to design appropriate interactions and interfaces.
Context scenarios address questions such as the following:
In what setting(s) will the product be used?
Will it be used for extended amounts of time?
Is the persona frequently interrupted?
Are there multiple users on a single workstation or device?
With what other products will it be used?
What primary activities does the persona need to perform to meet her goals?
What is the expected end result of using the product?
How much complexity is permissible, based on persona skill and frequency of use?
10_084113 ch06.qxp 4/3/07 6:03 PM Page 120
120
Part I: Understanding Goal-Directed Design
Context scenarios should not represent system behaviors as they currently are.
These scenarios represent the brave new world of Goal-Directed products, so, especially in the initial phases, focus on the goals. Don’t yet worry about exactly how things will get accomplished — you should initially treat the design as a bit of a magic black box.
In most cases, more than one context scenario is necessary. This is true especially when there are multiple primary personas, but sometimes even a single primary persona may have two or more distinct contexts of use.
Context scenarios are also entirely textual. We are not yet discussing form, only the behaviors of the user and the system. This discussion is best accomplished as a textual narrative.
An example context scenario
The following is an example of a first iteration of a context scenario for a primary persona for a personal digital assistant (PDA) type phone, including both the device and its service. Our persona is Vivien Strong, a real-estate agent in Indianapolis, whose goals are to balance work and home life, close the deal, and make each client feel like he is her only client.
Vivien’s context scenario:
1. While getting ready in the morning, Vivien uses her phone to check her e-mail. It has a large enough screen and quick connection time so that it’s more convenient than booting up a computer as she rushes to make her daughter, Alice, a sandwich for school.
2. Vivien sees an e-mail from her newest client, Frank, who wants to see a house this afternoon. The device has his contact info, so now she can call him with a simple action right from the e-mail.
3. While on the phone with Frank, Vivien switches to speakerphone so she can look at the screen while talking. She looks at her appointments to see when she’s free.
When she creates a new appointment, the phone automatically makes it an appointment with Frank, because it knows with whom she is talking. She quickly enters the address of the property into the appointment as she finishes her conversation.
4. After sending Alice off to school, Vivien heads into the real-estate office to gather some papers for another appointment. Her phone has already updated her Outlook appointments, so the rest of the office knows where she’ll be in the afternoon.
5. The day goes by quickly, and she’s running a bit late. As she heads towards the property she’ll be showing Frank, the phone alerts her that her appointment is in
10_084113 ch06.qxp 4/3/07 6:03 PM Page 121
Chapter 6: The Foundations of Design: Scenarios and Requirements
121
15 minutes. When she flips open the phone, it shows not only the appointment, but a list of all documents related to Frank, including e-mails, memos, phone messages, and call logs to Frank’s number. Vivien presses the call button, and the phone automatically connects to Frank because it knows her appointment with him is soon. She lets him know she’ll be there in 20 minutes.
6. Vivien knows the address of the property but is a bit unsure exactly where it is.
She pulls over and taps the address she put into the appointment. The phone downloads directions along with a thumbnail map showing her location relative to the destination.
7. Vivien gets to the property on time and starts showing it to Frank. She hears the phone ring from her purse. Normally while she is in an appointment, the phone will automatically transfer directly to voicemail, but Alice has a code she can press to get through. The phone knows it’s Alice calling, and uses a distinctive ring tone.
8. Vivien takes the call — Alice missed the bus and needs a pickup. Vivien calls her husband to see if he can do it. She gets his voicemail; he must be out of service range. She tells him she’s with a client and asks if he can get Alice. Five minutes later the phone makes a brief tone Vivien recognizes as her husband’s; she sees he’s sent her an instant message: “I’ll get Alice; good luck on the deal!”
Notice how the scenario remains at a fairly high level, without getting too specific about interfaces or technologies. It’s important to create scenarios that are within the realm of technical possibility, but at this stage the details of reality aren’t yet important. We want to leave the door open for truly novel solutions, and it’s always possible to scale back; we are ultimately trying to describe an optimal, yet still feasible, experience. Also notice how the activities in the scenario tie back to Vivien’s goals and try to strip out as many tasks as possible.
Pretending it’s magic
A powerful tool in the early stages of developing scenarios is to pretend the interface is magic. If your persona has goals and the product has magical powers to meet them, how simple could the interaction be? This kind of thinking is useful to help designers look outside the box. Magical solutions obviously won’t suffice, but figuring out creative ways to technically accomplish interactions that are as close to magical solutions as possible (from the personas’ perspective) is the essence of great interaction design. Products that meet goals with the minimum of hassle and intrusion seem almost magical to users. Some of the interactions in the preceding scenario may seem a bit magical, but all are possible with technology available today. It’s the goal-directed behavior, not the technology alone, that provides the magic.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 122
122
Part I: Understanding Goal-Directed Design
DESIGN
In early stages of design, pretend the interface is magic.
principle
Step 5: Identifying requirements
After you are satisfied with an initial draft of your context scenario, you can analyze it to extract the personas’ needs or requirements. These requirements can be thought of as consisting of objects, actions, and contexts.11 And remember, as we discuss above, we prefer not to think of requirements as identical to features or tasks.
Thus, a need from the scenario above might be:
Call (action) a person (object) directly from an appointment (context).
If you are comfortable extracting needs in this format, it works quite well; otherwise, you may find it helpful to separate them into data, functional, and contextual requirements, as described in the following sections.
Data requirements
Personas’ data needs are the objects and information that must be represented in the system. Using the semantics described above, it is often useful to think of data requirements as the objects and adjectives related to those objects. Common examples include accounts, people, documents, messages, songs, images, as well as attributes of those such as status, dates, size, creator, subject, and so on.
Functional requirements
Functional needs are the operations or actions that need to be performed on the objects of the system and which are typically translated into interface controls.
These can be thought of as the actions of the product. Functional needs also define places or containers where objects
or information in the interface must be displayed. (These are clearly not actions in and of themselves but are usually suggested by actions.)
Other requirements
After you’ve gone through the exercise of pretending it’s magic, it’s important to get a firm idea of the realistic requirements of the business and technology you are designing for (although we hope that designers have some influence over technology choices when it directly affects user goals).
Business requirements can include development timelines, regulations, pricing structures, and business models.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 123
Chapter 6: The Foundations of Design: Scenarios and Requirements
123
Brand and experience requirements reflect attributes of the experience you would like users and customers to associate with your product, company, or organization.
Technical requirements can include weight, size, form factor, display, power constraints, and software platform choices.
Customer and partner requirements can include ease of installation, maintenance, configuration, support costs, and licensing agreements.
Having performed these steps, you should now have a rough, creative overview of how the product is going to address user goals in the form of context scenarios, and a reductive list of needs and requirements extracted from your research, user models, and the scenarios. Now you are ready to delve deeper into the details of your product’s behaviors, and begin to consider how the product and its functions will be represented. You are ready to define the framework of the interaction.
Notes
1. Laurel, Computers as Theater, 134
2. Rheinfrank and Evenson, 1996
3. Carroll, 2001
4. Buxton, 1990
5. Verplank, et al, 1993
6. Wirfs-Brock, 1993
7. Constantine and Lockwood, 1999
8. Newman and Lamming, 1995
9. Holtzblatt and Beyer, 1998
10. Kuutti, 1995
11. Shneiderman, 1998
10_084113 ch06.qxp 4/3/07 6:03 PM Page 124
11_084113 ch07.qxp 4/3/07 6:03 PM Page 125
7
From Requirements to
Design: The Framework
and Refinement
In the previous chapter, we talked about the first part of the design process: developing scenarios to imagine ideal user interactions, and then defining requirements from these scenarios and other sources. Now we’re ready to design.
The Design Framework
Rather than jump into the nuts and bolts right away, we want to stay at a high level and concern ourselves with the overall structure of the user interface and associated behaviors. We call this phase of the Goal-Directed process the Design Framework.
If we were designing a house, at this point, we’d be concerned with what rooms the house should have, how they should be positioned with respect to each other, and roughly how big they should be. We would not be worried about the precise measurements of each room, or things like the doorknobs, faucets, and countertops.
The Design Framework defines the overall structure of the users’ experience, from the arrangement of functional elements on the screen, to interactive behaviors and
11_084113 ch07.qxp 4/3/07 6:03 PM Page 126
126
Part I: Understanding Goal-Directed Design
underlying organizing principles, to the visual and form language used to express data, concepts, functionality, and brand identity. In our experience, form and behavior must be designed in concert with each other; the Design Framework is made up of an interaction framework, a visual design framework, and sometimes an industrial design framework. At this phase in a project, interaction designers use scenarios and requirements to create rough sketches of screens and behaviors that make up the interaction framework. Concurrently, visual designers use visual language studies to develop a visual design framework that is commonly expressed as a detailed rendering of a single screen archetype, and industrial designers execute form language studies to work towards a rough physical model and industrial design framework. Each of these processes is addressed in this chapter.
When it comes to the design of complex behaviors and interactions, we’ve found that focusing on pixel-pushing, widget design, and specific interactions too early can get in the way of effectively designing a comprehensive framework that all of the product’s behaviors can fit within. By taking a top-down approach, concerning ourselves first with the big picture and rendering our solutions without specific detail in a low-fidelity manner, we can ensure that we and our stakeholders stay initially focused on the fundamentals: serving the personas’ goals and requirements.
Revision is a fact of life in design. Typically, the process of representing and presenting design solutions helps designers and stakeholders refine their vision and understanding of how the product can best serve human needs. The trick, then, is to render the solution only in enough detail to provoke engaged consideration, without spending too much time or effort creating renderings that are certain to be modified or abandoned. We’ve found that sketchlike storyboards, accompanied by narrative in the form of scenarios, are a highly effective way to explore and discuss design solutions without creating undue overhead and inertia.
Research about the usability of architectural renderings supports this notion. A study of people’s reactions to different types of CAD images found that pencil-like sketches encouraged discourse about a proposed design, and also increased understanding of the renderings as representing work-in-progress.1 Carolyn Snyder covers this concept at length in Paper Prototyping, where she discusses the value of such low-fidelity presentation techniques in gathering user feedback. While we believe that usability testing and user feedback is often most constructive during design refinement, there are certainly cases where it is useful as early as the Framework phase. (More discussion of usability testing can be found at the end of the chapter.)
11_084113 ch07.qxp 4/3/07 6:03 PM Page 127
Chapter 7: From Requirements to Design: The Framework and Refinement 127
Defining the interaction framework
The interaction framework defines not only the high-level structure of screen layouts but also the flow, behavior, and organization of the product. The following six steps describe the process of defining the interaction framework: 1. Define form factor, posture, and input methods
2. Define functional and data elements
3. Determine functional groups and hierarchy
4. Sketch the interaction framework
5. Construct key path scenarios
6. Check designs with validation scenarios
While we’ve broken the process down into numerically sequenced steps, this is not typically a linear effort, but rather occurs in iterative loops. In particular, Steps 3–5
may be swapped around, depending on the thinking style of the designer (more on this later). The six steps are described in the following sections.
Step 1: Define form factor, posture, and input methods
The first step in creating a framework is to define the form factor of the product you’ll be designing. Is it a Web application that will be viewed on a high-resolution computer screen? Is it a phone that must be small, light, low-resolution, and visible in both the dark and bright sunlight? Is it a kiosk that must be rugged to withstand a public environment while accommodating thousands of distracted, novice users?
What are the constraints that each of these imply for any design? Each of these form factors has clear implications for the design of the product, and answering this question sets the stage for all subsequent design efforts. If the answer isn’t obvious, look to your personas and scenarios to better understand the ideal usage context and environment. Where a product requires the design of both hardware and software, these decisions also involve industrial design considerations. Later in the chapter we discuss how to coordinate interaction design with industrial design.
/> As you define the form, you should also define the basic posture of the product, and determine the input method(s) for the system. A product’s posture is related to how much attention a user will devote to interacting with the product, and how the product’s behaviors respond to the kind of attention a user will be devoting to it.
This decision should be based upon usage contexts and environments as described in your context scenario(s) (see Chapter 6). We discuss the concept of posture in greater depth in Chapter 9.
11_084113 ch07.qxp 4/3/07 6:03 PM Page 128
128
Part I: Understanding Goal-Directed Design
The input method is the way users will interact with the product. This will be driven by the form factor and posture, as well as by your personas’ attitudes, aptitudes, and preferences. Choices include keyboard, mouse, keypad, thumb-board, touch screen, voice, game controller, remote control, dedicated hardware buttons, and many other possibilities. Decide which combination is appropriate for your primary and secondary personas. In cases where it may be appropriate to use a combination of input methods (such as the common Web site or desktop application that relies on both mouse and keyboard input), decide upon the primary input method for the product.
Step 2: Define functional and data elements
Functional and data elements are the representations of functionality and data that are revealed to the user in the interface. These are the concrete manifestations of the functional and data requirements identified during the Requirements Definition phase. Where the requirements were purposely described in general terms, from the personas’ perspective, functional and data elements are described in the language of user-interface representations. It is important to note that these elements must each be defined in response to specific requirements defined earlier. This is how we ensure that every aspect of the product we are designing has a clear purpose that can be traced back to a usage scenario or business goal.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 20