Data elements are typically the fundamental subjects of interactive products.
These objects, such as photos, e-mail messages, customer records, or orders, are the basic units to be referred to, responded to, and acted upon by the people using the product, and ideally should fit with the personas’ mental models. At this point, it is critical to comprehensively catalog the data objects, because the product’s functionality is commonly defined in relation to them. We are also concerned with the significant attributes of the objects (for example, the sender of an e-mail message or the date a photo was taken), but it is less important to be comprehensive about the attributes at this point, as long as you have an idea whether the personas care about a few attributes or a lot.
It’s useful to consider the relationships between data elements. Sometimes a data object may contain other data objects; other times there may be a more associative relationship between objects. Examples of such relationships include a photo within an album, a song within a playlist, or an individual bill within a customer record.
Functional elements are the operations that can be done to the data elements and their representations in the interface. Generally speaking, they include tools to act upon data elements and places to put data elements. The translation of functional requirements into functional elements is where we start making the design
11_084113 ch07.qxp 4/3/07 6:03 PM Page 129
Chapter 7: From Requirements to Design: The Framework and Refinement 129
concrete. While the context scenario is the vehicle to imagine the overall experience we will be creating for our users, this is where we make that experience real.
It is common that a single requirement will necessitate multiple interface elements.
For example, Vivien, our persona for a smartphone from Chapter 6, needs to be able to telephone her contacts. Functional elements to meet that need include:
Voice activation (voice data associated with contact)
Assignable quick-dial buttons
Selecting a contact from a list
Selecting a contact from an e-mail header, appointment, or memo
Auto-assignment of a call button in appropriate context (for example, upcoming appointment)
Again, it is imperative to return to context scenarios, persona goals, and mental models to ensure that your solutions are appropriate to the situation at hand. This is also the place in the process where design principles and patterns begin to become a useful way to arrive at effective solutions without reinventing the wheel.
You also must exercise your creativity and design judgment here. In response to any identified user requirement, there are typically quite a number of possible solutions. Ask yourself which of the possible solutions is most likely to:
Accomplish user goals most efficiently?
Best fit our design principles?
Fit within technology or cost parameters?
Best fit other requirements?
Pretend the product is human
As you saw in Chapter 6, pretending a tool, product, or system is magic is a powerful way to imagine the ideal user experience to be reflected in concept-level context scenarios. In the same way, pretending the system is human is a powerful tool to structure interaction-level details. This simple principle is discussed in detail in Chapter 12. In a nutshell, interactions with a digital system should be similar in tone and helpfulness to interactions with a polite, considerate human.2 As you determine the interactions and behavior along with the functional elements and groupings, you should ask yourself: What would a helpful human do? What would a thought-ful, considerate interaction feel like? Is the primary persona being treated humanely by the product? In what ways can the software offer helpful information without getting in the way? How can it minimize the persona’s effort in reaching his goals?
11_084113 ch07.qxp 4/3/07 6:03 PM Page 130
130
Part I: Understanding Goal-Directed Design
For example, a mobile phone that behaves like a considerate person knows that, after you’ve completed a call with a number that isn’t in your contacts, you may want to save the number, and provides an easy and obvious way to do so. An inconsiderate phone forces you to scribble the number on the back of your hand as you go into your contacts to create a new entry.
Apply principles and patterns
Critical to the translation of requirements to functional elements (as well as the grouping of these elements and the exploration of detailed behavior in scenarios and storyboards) is the application of general interaction principles and specific interaction patterns. These tools leverage years of interaction design experience.
Neglecting to take advantage of such knowledge means wasting time on problems whose solutions are well known. Additionally, deviating from standard design patterns can create a product where the users must learn every interaction idiom from scratch, rather than recognizing behaviors from other products and leveraging their own experience (we discuss the idea of design patterns in Chapter 8). Of course, sometimes it is appropriate to invent new solutions to common problems, but as we discuss further in Chapter 14, you should obey standards unless you have a darn good reason not to.
Scenarios provide an inherently top-down approach to interaction design. They iterate through successively more detailed design structures, from main screens down to tiny subpanes or dialogs. Principles and patterns add a bottom-up approach to balance the process. Principles and patterns can be used to organize elements at all levels of the design. Chapter 8 discusses the uses and types of principles and patterns in detail, and the chapters of Parts II and III provide a wealth of useful interaction principles appropriate to this step in the process.
Step 3: Determine functional groups and hierarchy
After you have a good list of top-level functional and data elements, you can begin to group them into functional units and determine their hierarchy.3 Because these elements facilitate specific tasks, the idea is to group elements to best facilitate the persona’s flow (see Chapter 10) both within a task and between related tasks. Some issues to consider include:
Which elements need a large amount of video real estate and which do not?
Which elements are containers for other elements?
How should containers be arranged to optimize flow?
Which elements are used together and which aren’t?
In what sequence will a set of related elements be used?
11_084113 ch07.qxp 4/3/07 6:03 PM Page 131
Chapter 7: From Requirements to Design: The Framework and Refinement 131
What interaction patterns and principles apply?
How do the personas’ mental models affect organization?
At this point it’s important to organize data and functions into top-level container elements, such as screens, frames, and panes. These groupings may change somewhat as the design evolves (particularly as you sketch out the interface), but it’s still useful to provisionally sort elements into groups as this will speed up the process of creating initial sketches.
Consider which primary screens or states (which we’ll call views) the product requires. Initial context scenarios give you a feel for what these might be. If you know that a user has several end goals and needs where data and functionality don’t overlap, it might be reasonable to define separate views to address them. On the other hand, if you see a cluster of related needs (for example, to make an appointment, your persona needs to see a calendar and contacts), you might consider defining a view that incorporates all these together.
When grouping functional and data elements, consider how they should be arranged given the product’s platform, screen size, form factor, and input methods.
Containers for objects that must be compared or used together should be adjacent to each other. Objects representing steps in a process should, in general, be adjacent and ordered sequentially. Use of interaction design principles and patterns is extremely helpful at this juncture; Part III of
this book provides many principles that can be of assistance at this stage of organization.
Step 4: Sketch the interaction framework
Now we’re ready to sketch the interface. This visualization of the interface should be extremely simple at first. Around the studio, we often refer to this as “the rectangles phase” because our sketches start out by subdividing each view into rough rectangular areas corresponding to panes, control components (such as toolbars), and other top-level containers (see Figure 7-1). Label the rectangles, and illustrate and describe how one grouping or element affects others.
You may want to sketch different ways of fitting top-level containers together in the interface. Sketching the framework is an iterative process that is best performed with a small, collaborative group of one or two interaction designers and a visual or industrial designer. This visualization of the interface should be extremely simple at first: boxes representing each functional group and/or container with names and descriptions of the relationships between the different areas (see Figure 7-1).
11_084113 ch07.qxp 4/3/07 6:03 PM Page 132
132
Part I: Understanding Goal-Directed Design
Figure 7-1 Example of an early framework sketch from designs Cooper created for Cross Country TravCorps, an online portal for traveling nurses. Framework sketches should be simple, starting with rectangles, names, and simple descriptions of relationships between functional areas. Details can be visually hinted at to give an idea of contents, but don’t fall into the trap of designing detail at this stage.
Be sure to look at the entire, top-level framework first; don’t let yourself get distracted by the details of a particular area of the interface (although imagining what goes into each container will help you decide how to arrange elements and allocate real estate). There will be plenty of time to explore the design at the widget level later; trying to do so too soon may risk a lack of coherence in the design as you move forward. At this high-level, “rectangle phase,” it’s very easy to explore a variety of ways of presenting information and functionality and to perform radical reorganizations, if necessary. It’s often useful to try several arrangements on for size, running through validation scenarios (see Step 6, below), before landing on the best solution. Spending too much time and effort on intricate details early in the design process discourages designers from changing course to what might be a superior solution. It’s easier to discard your work and try another approach when you don’t have a lot of effort invested.
11_084113 ch07.qxp 4/3/07 6:03 PM Page 133
Chapter 7: From Requirements to Design: The Framework and Refinement 133
Sketching the framework is an iterative process that is best performed with a small, collaborative group of one or two interaction designers (or ideally an interaction designer and a “design communicator” — someone who thinks in terms of the narrative of the design) and a visual or industrial designer. We haven’t found a better tool for initial sketches than a simple whiteboard. Working at a whiteboard promotes collaboration and discussion and, of course, everything is easy to erase and redraw. A digital camera provides a quick and easy means to capture ideas for later reference.
Once the sketches reach a reasonable level of detail, it becomes useful to start rendering in a computer-based tool. Each has its strengths and weaknesses, but tools commonly used to render high-level interface sketches include Adobe Fireworks, Adobe Illustrator, Microsoft Visio, Microsoft PowerPoint, and Omni Group’s OmniGraffle. The key here is to find the tool that is most comfortable for you, so you can work quickly, roughly, and at a high level. We’ve found it useful to render Framework illustrations in a visual style that suggests the sketchiness of the proposed solutions (recall that rough sketches tend to do a better job promoting discourse about design). It is also critical to be able to easily render several related, sequential screen states to depict the product’s behavior in the key path scenario (the “Frames” construct in Fireworks makes it a particularly good tool for doing this).
Step 5: Construct key path scenarios
A key path scenario describes how the persona interacts with the product, using the vocabulary of the interaction framework. These scenarios depict the primary pathways through the interface that the persona takes with the greatest frequency, often on a daily basis. Their focus is at the task level. For example, in an e-mail application, key path activities include viewing and composing mail, not configuring a new mail server.
These scenarios typically evolve from the context scenarios, but here we specifically describe the persona’s interaction with the various functional and data elements that make up the interaction framework. As we add more and more detail to the interaction framework, we iterate the key path scenarios to reflect this detail in greater specificity around user actions and product responses.
Unlike the goal-oriented context scenarios, key path scenarios are more task oriented, focusing on task details broadly described and hinted at in the context scenarios. This doesn’t mean that we can ignore goals — goals and persona needs are the constant measuring stick throughout the design process, used to trim unnecessary tasks and streamline necessary ones. However, key path scenarios must describe in exacting detail the precise behavior of each major interaction and provide a walkthrough of each major pathway.
11_084113 ch07.qxp 4/3/07 6:03 PM Page 134
134
Part I: Understanding Goal-Directed Design
Storyboarding
By using a sequence of low-fidelity sketches accompanied by the narrative of the key path scenario, you can richly portray how a proposed design solution helps personas accomplish their goals. This technique of storyboarding is borrowed from filmmaking and cartooning, where a similar process is used to plan and evaluate ideas without having to deal with the cost and labor of shooting actual film. Each interaction between the user and the product can be portrayed on one or more frames or slides. Advancing through them provides a reality check for the coherence and flow of the interactions (see Figure 7-2).
Process variations and iteration
Because creative human activities are rarely a sequential, linear process, the steps in the Framework phase shouldn’t be thought of as a simple sequence. It is common to move back and forth between steps and to iterate the whole process several times until you have a solid design solution. Depending on how you think, there are a couple different ways to approach Steps 3–5. You may find that one works better for you than another.
Figure 7-2 An example of a more evolved Framework rendering from the Cross Country TravCorps job search Web application.
11_084113 ch07.qxp 4/3/07 6:03 PM Page 135
Chapter 7: From Requirements to Design: The Framework and Refinement 135
Verbal thinkers may want to use the scenario to drive the process and approach Steps 3–5 in the following sequence (as described above):
1. Key path scenarios
2. Work out the groupings verbally
3. Sketch
Visual thinkers may find starting from the illustration will help them make sense of the other parts of the process. They may find this easier:
1. Sketch
2. Key path scenarios
3. See if your groupings work with the scenarios
Step 6: Check designs with validation scenarios
After you have storyboarded your key path scenarios and adjusted the interaction framework until the scenario flows smoothly and you’re confident that you’re headed in the right direction, it is time to shift focus to less frequent or less important interactions. These validation scenarios are not typically developed in as much detail as key path scenarios. Rather, this phase consists of asking a series of
“what if . . .” questions. The goal here is to poke holes in the design and adjust it as needed (or throw it out and start over). There are three major categories of validation scenarios that should be addressed in the following order:
Key path variant scenarios are alternate
or less-traveled interactions that split off from key pathways at some point along the persona’s decision tree. These could include commonly encountered exceptions, less frequently used tools and views, and variations or additional scenarios based upon the goals and needs of secondary personas. Returning to our smartphone scenario from Chapter 6, an example of a key path variant would be if Vivien decided to respond to Frank by e-mail in Step 2 instead of calling him.
Necessary use scenarios include those actions that must be performed, but only infrequently. Purging databases, configuring, and making other exceptional requests might fall into this category. Necessary use interactions demand pedagogy because they are seldom encountered: Users may forget how to access the function or how to perform tasks related to it. However, this rare use means that users won’t require parallel interaction idioms such as keyboard equivalents, nor do such functions need to be user-customizable. An example of a necessary use scenario for the design of a smartphone is if the phone was sold second-hand, requiring the removal of all personal information associated with the original owner.
11_084113 ch07.qxp 4/3/07 6:03 PM Page 136
136
Part I: Understanding Goal-Directed Design
Edge case use scenarios, as the name implies, describe atypical situations that the product must nevertheless be able to handle, albeit infrequently. Programmers focus on edge cases because they often represent sources of system instability and bugs, and typically require significant attention and effort. Edge cases should never be the focus of the design effort. Designers can’t ignore edge case functions and situations, but the interaction needed for them is of much lower priority and is usually buried deep in the interface. Although the code may succeed or fail on its capability to successfully handle edge cases, the product will succeed or fail on its capability to successfully handle daily use and necessary cases. Returning once again to Vivien’s smartphone (in Chapter 6), an example of an edge case scenario would be if Vivien tried to add two different contacts with the same name. This is not something she is likely to want to do, but something the phone should handle if she does.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 21
