14
The User Environment Design
Abstract
A new product or feature set must have the appropriate function and structure to support a natural flow of interaction. For that, Contextual Design uses the User Environment Design. The User Environment Design is a floor plan of the new product showing the places in the product, the function in that place, and the links between one place and another. It shows the parts of the product from the user's point of view and helps the team think structurally about the product. In this chapter we describe the User Environment Design, show how it is represented, and lay out the process for building one from the storyboards.
Keywords
Business analysis; Consistency; Cool concepts; Design; Design thinking; Human–computer interaction (HCI); Human–machine interaction; Information architecture; Marketing; Mobile design; Product design; Requirements gathering; System design; Usability; User-centered design; User environment design; User experience; User interface architecture; User research; UX
Just as storyboards keep the practice coherent, the User Environment Design keeps the product or coordinated suite of products coherent. Designers now have to consider the whole ecosystem of apps, websites, and software tools that work together across devices to support the overall intent of the user relative to the target activity. Whether you are designing one product or a larger ecosystem, designers need a way of seeing, defining, and structuring the overall product offering. When we first introduced the User Environment Design, people were mainly designing software applications and that’s how we talked about it. But the basic concepts and structure of the User Environment Design are just as applicable today.
The job of the User Environment Design is to represent the overall product structure including across application boundaries. It shows the places where user interacts with the product, the function and content within those places, the way information is brought into each place, and the pathways for the user to move between places. Blocking out the overall structure of the system as a set of places, each focused on allowing the user to achieve a particular purpose, is the first challenge for the design team. The structural decisions of the User Environment Design precede decisions about the implementation or user interface. It doesn’t make sense to design screen layouts until you’ve decided what places will be in the system and what functions the system should implement.
In the User Environment Design, places are defined by Focus Areas, a core concept for structuring the user experience. Focus areas define a set of function and content all oriented toward achieving a particular purpose or user intent. A user moves from one focus area to another as needed to perform an activity. Consider this example:
A user takes a break from a heads-down task by checking email. First she scans her messages looking for something interesting. She doesn’t want work email that will draw her into another difficult task—she wants a break. So she doesn’t want the whole content of the email—sender and subject line are enough to pick out something fun. Fortunately, there’s an email from her husband proposing a vacation spot. Just the thing. She clicks on the email.
Up to this point this user has been in one place, the inbox, with one set of functions for reading, scanning, organizing, and deleting messages. Once she opens the message, she’s in a new place. Her intent has changed; she’s no longer looking for an email to read, she’s focused in on the content of one email. She’s reading the one message from her husband and she’s got functions appropriate to that intent—read, reply, file, delete, and most importantly, click on link. Some functions were also found in the inbox; others were not. This new collection of function provided by this new place matches her new intent.
Her husband is suggesting a trip to New Zealand. Fun! She clicks the link he sent—and now she’s in a new place, the vacation resort’s website.
The new place has new function appropriate to her new intent (to see if she would like this resort). It was created by a different set of people, at a different time, without knowledge of her email app, but in this interconnected world, that doesn’t matter. Her experience is that of moving from place to place, following her intent as that evolves given the information she takes in at each place.
Now suppose it’s our goal to build a product supporting travel planning. Our user’s intent, once she reaches the resort’s page, is to talk about it with her husband, find additional things to do in New Zealand, forward the page to a friend who’s been there for advice, and so forth. How does our new product fit into this existing ecology? Do we work with resorts to capture information from their pages, or with email providers to communicate vacation ideas between users? If that won’t work for technical and business reasons, do we adopt a model like Pinterest’s “Pin It” widget, an add-on that’s available everywhere?
Suppose we have such a browser widget. How does it work? Does it pull the user out of whatever place they were in into a new place where they can make notes and send the idea to others? That might be good—maybe commenting on the resort is sufficiently different from exploring it online that a new place will work. Or maybe it’s not—maybe the user really doesn’t want to lose the context of the place she’s commenting on. Then how do we design our app so that the user experience is not that of leaving the place? What about other platforms—maybe users will want to do more in-depth exploration over lunch on their cell phone. Can they pick up where they left off? Is there an app on the phone and what exactly does it do?
These are the challenges of product design: create the necessary places on the right platforms to support the flexibility of the activity; design the right function into those places; and design the right access from place to place so the flow of the user’s work is not interrupted. User-centered design seeks to build a structure for the overall product which supports the user’s natural movement through their activities and is flexible enough that the user can invent new ways of working.
Designing product structure is designing to support the user practice as it moves through the places in the product. To design the product structure, you must be able to think about the places, their purpose, and their connection irrespective of any particular user interface or implementation. But this kind of structural thinking is hard for teams. In our early work with design teams, we found that team members tended to slide into conversations about the user interface before they were ready—before they had agreed on base structure. They were like architects who could only communicate by drawing pictures focused on detail inside the rooms of the proposed house instead of the overall plan for the house as a structure. “We want this function on this page,” one would say, sketching a row of buttons. “The style guide says those should be side navigation,” another would reply. “Do you really want to use that word?” a third would ask. When the very language you use to communicate suggests that the user interface is the topic of conversation, it’s hard not to be distracted by it.
The same thing happens when developers are on the team—they want to talk about specific algorithms, data access, and whether a particular function is doable automatically. We do need to know if a technical concept is doable, but we don’t need to lay the pipes and locate the electrical outlets inside the rooms of the house before knowing what the overall layout of the house will be. So we needed a way to represent the system structure directly, free of any user interface or technical implications. The User Environment Design was designed explicitly to help teams see structure and hold off on detailed design, whether it’s the user interface or the technical underpinnings. And to build it we borrowed from building architecture.
The oldest form of design for life is in architecture—building a house. We live in the places in our house, we walk through the rooms and hallways, and we do things in those rooms. An architect of a new home would never start by choosing rugs and materials for the countertops. Instead, they start with rough sketches which they work up into a floor plan. The floor plan captures the right level of detail for talking about the structure of a house—it shows the parts and their relationships without showing how the house is decorated. The user interface of a product is equivalent to the decoration of a house—it matters, but if the structure is wrong, no user interface can fix the problems.
The pattern of use we found in software—working in a place, moving to a new location, and doing a new kind of activity based on a new intent in that place—is very much like living in a house. A person starts dinner and goes to the kitchen where the tools for cooking are located (knives, bowls, stove). A drawer sticks, and he decides to take it to the workshop and plane it down while the water boils. He takes the drawer to another place, which has the different set of tools useful for minor carpentry, and works on the drawer there. Then he goes back to finish dinner. A house consists of places to do things, functions or tools in each place which help do things, and access allowing people to move between places. The parallels between living and working in software and in houses suggested the idea of creating a system floor plan—the User Environment Design.1
Figure 14.1 A floor plan. Notice how the important distinctions are immediately apparent—the relative size of the spaces and the access between them. Details which are unimportant for understanding the structure of the house—rugs, wall surface—are absent or inconspicuous. But the drawing does tie to the users’ experience of moving through a house and also puts construction details in context—the dark squares in the walls indicate supporting posts and the numbers in circles key this diagram to cross-sections showing wall construction. This is what we need in software design—a single representation which shows how all the parts of the system relate in the users’ experience.
A floor plan occupies a unique role in the design of a house (Fig. 14.1). It’s less physical than an elevation, which shows a view of the house as though you were looking at it (an elevation is more like a user interface sketch). It doesn’t show wall color or how the house is finished (which would also be more like a user interface). Yet it’s not at the nuts-and-bolts level of a construction diagram (for the implementation), which might show how to put a wall together but doesn’t show anything the homeowner can relate to. The floor plan selects a few of the most salient aspects of a house as it supports living and represents them: the spaces in the house, their sizes, and relationships to each other; the large things in each space which support the kind of living done there (stoves, refrigerators); and the access between spaces.
As a diagram, a floor plan supports a conversation about how well a design supports a particular style of life and allows the architect to compare that with the life the house’s prospective owners want to have. Architects can walk stories of living through the floor plan to see how well it fits the homeowners. Is a room too small for the way the owners want to use it? Is it too hard to get from one room to another? Is there a lot of dead space devoted to halls or intermediate areas? The floor plan lays out all the parts of a house, letting the architect walk different cases and scenarios through it. Rules of thumb such as constraints on minimum clearances, layouts which work well, and the limitations of construction materials ensure that the resulting design is usable and implementable. Of course, once the house is built, meals may be eaten in the kitchen, and a formal dining room may be used as a music room. But this homeowner simply redefined the “place” next to the kitchen to be a “place” for music by bringing all their instruments and music into that place. The place is still coherent—it has a fundamental purpose—it’s just not dining. A good structure will permit different uses which the architect never designed explicitly.
Seeing and designing structure is critical for ensuring that both the life and the product hang together to support the user. Architects made a way to see the structure of their buildings when they invented floor plans. The User Environment Design represents the product structure in the same kind of way. It is built first at a high level, revealing the overall structure of the product. Then as the basic concept is validated, it becomes the specification of what needs to be built. Each place in the User Environment Design will be a screen, page, or window where the user will interact with the product. Just as a room in a house needs layout to ensure it works for the purpose of the room, a place in a software product needs layout so that the support activities can be done conveniently in that place. Interaction Patterns (discussed in Chapter 15) define the structure of each place and guide the user interface approach and architecture as a whole.
The User Environment Design elements
In life, people move from intent to intent to get their work and life done. They engage in a variety of activities to accomplish these intents. And there’s a natural flow through these activities—users will move from one activity to another, depending on what they are trying to achieve. A user-centered product, one that supports the user well, should provide direct support to help the user fulfill his or her intents by organizing the right function into coherent areas that map to specific user activities.
Just as any house has a floor plan, no matter how it was designed, any product has a User Environment Design implicit within it. Any product can be analyzed and its underlying User Environment Design revealed. (In fact, doing a reverse User Environment Design is one of the best ways to find the structural problems that may be plaguing your existing product.) So to illustrate the User Environment Design, we’ll use an example most people are familiar with: Microsoft PowerPoint.
Figure 14.2 A screen from PowerPoint. This is the editing window, where individual slides can be designed. Note the nav bar on the left, which lets the user see the local neighborhood of the slide; and the area at the bottom for presenter notes.
Figure 14.3 The Focus Area defining the editing screen (partial). The purpose highlights the user’s intent on this Focus Area; the functions list what the user can do at a high level. Further design iterations will define these functions more comple.
Fig. 14.2 shows PowerPoint’s slide editing screen. The primary purpose of this place is for creating and editing the content of slides. In the User Environment Design we represent places as Focus Areas, where the user focuses on doing a certain kind of activity. Every Focus Area has a purpose: a succinct statement of the primary intent the Focus Area supports. If you can’t write a single sentence which describes the purpose of the Focus Area, it’s likely that the product is poorly structured, either because there are so many different functions doing different things or because the place supports no coherent activity at all (Fig. 14.3).
This window provides functions which enable doing work in the place—to put shapes, text boxes, and other slide objects on the slide, color and rotate them, and manipulate them in other ways. Functions are made available through menus, toolbars, keyboard commands, and by direct manipulation. These are alternative interaction mechanisms for performing a function; some functions can be accessed all three ways (e.g., to save the presentation, choose “Save” under the “File” menu, click the disk icon on the toolbar, or, on Windows, press ctrl-s). Which mechanism the interaction designers will choose to implement for a function matters—a poor user interface or inconvenient access to function gets in the users’ way—but it doesn’t change the purpose of the place or the work done there. The interaction mechanisms and screen layout are as much a distraction to understanding product structure as rug color would be on a floor plan. So we list the functions in a Focus Area once, with no indication of how they are accessed. (“Save slide show”).
Some functions in a Focus Area are things the underlying system does on behalf of the user: “Show slide content.” Some functions can be invoked by the user: “Edit slide content”. And other functions are links, taking the user to another place in the product: “Bring up Slide Sorter.”
Functions that lead to other places in the product change the view and the function available—once the user has switched to the slide sorter Focus Area, it is no longer possible to edit the content of slides. Instead, the slide sorter supports viewing a whole presentation in order, changing the order of slides, and controlling the transition from slide to slide. Since the work which can be done is different, the slide sorter supports a new activity in a new place, and we represent it with a new Focus Area. You’d expect to find these links between Focus Areas whenever the user might need to switch between the activities they support (Fig. 14.4).
Figure 14.4 Links between Focus Areas. These Focus Areas support distinct but related activities. By this design, when the user is thinking about the overall flow of the presentation, she is not thinking about how to design an individual slide, so those areas can be separated. But when thinking about the slide content, she may well want to add to presenter notes, so those are naturally in the same Focus Area.
Back on the “Edit Slide” screenshot, note the list of slides in the pane on the left. This is a navigation tool, like the left navigation bars found on web pages. It’s not a separate Focus Area—no independent work is done there. Instead it provides three functions: it shows where the current slide lies in the context of the slideshow, helping the user track continuity; it lets the user jump to another slide; and it lets the user do local reordering of slides via drag and drop right in that pane. But reordering slides is the primary purpose of the slide sorter Focus Area. Is this duplication of function wrong or confusing? Should there be only one place to reorder slides?
No. It’s easy to start thinking logically about the design, and logic is never user centered. When a presenter is looking at a slide, it’s natural to think how it flows with the slides before and after—how this piece of the presentation’s story hangs together. So it’s natural to rethink the ordering, and choose to rearrange slides just for this piece of the presentation. That’s quite different from thinking about the overall presentation: the introduction, discussion, and wrap up. Users don’t get confused when function is available in two places—they get annoyed when the function they want isn’t available in the place they’re in.
The presenter notes at the bottom of PowerPoint’s screen are another interesting case in point. In early versions of PowerPoint, presenter notes were brought up in their own window—in a separate Focus Area. But it’s common when preparing a presentation to add to the notes while editing a slide. Writing the slide content reminds the presenter of a point they want to make, so they add it to the notes. Or some content won’t fit on the slide, so the presenter decides that they can just talk about that point—but they copy it to the notes so they don’t forget. So there’s a tight, organic interaction between slide and notes. Separating them into different Focus Areas made the work flow cumbersome. Over time, the PowerPoint team recognized the problem and merged the Focus Areas.
In PowerPoint, all the content is supplied by the user. Other products—a news site presenting stories, a shopping site presenting products, or a booking site presenting flight options—have content of their own which needs to be organized and presented. In such cases, the User Environment Design will list the content the Focus Area provides as well as the function to manipulate it.
While designing Focus Areas, consider the platforms they need to support. Some will work reasonably well on any platform—they just need an appropriate user interface, which can be different on each platform. This function and content can be represented in one Focus Area with a note listing the platforms it needs to be delivered on (desktop, web, tablet, or something else). Other Focus Areas need to support users on the go, which means they must be optimized for partial attention and quick action, and functionality may be limited by screen size. These will form a mobile subsystem in the User Environment Design. Still, other Focus Areas support heads-down, focused work and don’t need to consider any mobile platform. The User Environment Design captures the whole ecosystem of support the team plans to deliver (Fig. 14.5).
Readers of the first edition of this book may notice that the formalism here is very much simplified. When the first edition came out, many formalisms were in common use and familiar to teams—RUP, object modeling, and Use Cases, to name a few. Those formalisms have largely fallen out of regular use and designers are much less familiar with the concept of formalisms in general. So we’ve simplified the presentation of the User Environment Design to be more direct and immediate.
Building the User Environment Design from storyboards
The User Environment Design is built directly from storyboards. Storyboards represent the team’s plan for how people will perform their activities within the new product and ecosystem. But storyboards only consider one task at a time. Now we will review all the core tasks looking for what places, functions, content, and links they imply are needed. As we move from storyboard to storyboard, rolling in the implications of each, the team can start to see what core places are needed in the product. They may have an idea of the primary places needed, but this systematic way of pulling them out of storyboards ensures that the design provides all the functions and all the links needed to support the team’s vision concepts.
Returning to our house analogy, imagine all the storyboards we might create for cooking: the quick microwaved hot dog, the Thanksgiving dinner, making kids lunches. A good place will support all these kinds of cooking, simple or complex, supporting each well. This is what a good kitchen is—everything you need to do the work of cooking from simple to complex is available conveniently, and nothing you don’t need is there. We don’t create a microwaving room and a separate fancy cooking room, any more than we create a refrigeration room and down the hall a food washing room. Instead, we bring all that is needed to do the work of cooking into one place. A storyboard presents the users’ actions linearly but a good product will not be linear; your job is to find the implied places in the stories and assemble them and the function they need into a coherent structure. Then when you encounter the next cooking story, you first ask whether you can reuse a place you already have, maybe adding to or twisting it a bit to accommodate the new story. Need to support the microwaved hot dog in our fancy kitchen? Let’s just add a microwave near the refrigerator.
Storyboards tell a single story of use: “I’m a user exploring a travel opportunity. How do I approach it? What do I do?” A scenario-based approach to design ensures the product hangs together for a single scenario of use, but it tends to hide the relationship to any other scenarios. In contrast, the User Environment Design supports structural thinking: “What’s really going on in this place? Is it supporting a single, coherent activity? Does it provide everything the user needs to do that activity?” Storyboards alone can lead to a particular kind of tunnel vision—“The user is doing online purchasing? Where’s the function for filtering products by price?” “Oh—our storyboard wasn’t concerned with price, so we didn’t think of that function.” “But this is a shopping place—of course it has to have that function.” Thinking about the place as a coherent whole identifies additional needs. But be careful of overcomplicating a design by brainstorming into the Focus Area. Add new function if the Focus Area makes no sense without it; otherwise, identify new storyboards and sketch out the new function in the context of the user and your data.
With storyboards and the User Environment Design working together, each focused on supporting one kind of thinking well, the conversations can be separated for the team, making them clearer and easier to have and making it easier for the team to really focus on each.
To build the User Environment Design, review the storyboards one at time, asking what place is needed to support this step of the story and what function and content is needed in that place. Storyboards implicitly define requirements for the User Environment Design; pull these implications out by walking through it cell by cell. Each cell may suggest a new Focus Area, function, content, or link in the emerging User Environment Design. The pictorial nature of storyboards help you recall the context and design implications of each cell far better than a written scenario or description. As you walk each cell, ask whether the user is in a new Focus Area, or whether you can reuse one already in the User Environment Design. Same for functions and links—has the storyboard added a new function or reused an existing function? If you are extending an existing product, start with a high-level reverse User Environment Design of the product and roll your new function into that to keep the product coherent. Discuss these implications and revise or extend the User Environment Design to capture your decisions.
Here’s how the process works in practice. Note that for brevity when we show the functions added to a Focus Area, we are just showing the additions—all prior function and purpose statements are still there.
The first storyboard cell defines a widget to appear in standard browser windows so the user can capture travel ideas. The user doesn’t need to look at it, but the cell implies an Idea Collector Focus Area. Here is an example where the product has to interact with the ecosystem to deliver its value. So the Focus Area is the browser window—the team envisions using an extension to add function.
1. Browser Window
Purpose: Capture interesting travel information during normal browsing.
Function:
• User can save a page to their Idea Collector without interrupting their browsing.
2. Idea Collector
Purpose: Collect trip ideas into one place for later consideration.
Function:
• User can save a webpage to their Idea Collector.
Now the storyboard has the user go to the Idea Collector. This cell starts to flesh out what’s there—ideas captured by the user and more generated by the product. Any thinking about product behavior (the suggestion engine) is captured with its related function.
2. Idea Collector
Purpose: Collect trip ideas for later perusal and elaboration.
Function:
• User can save a webpage to his or her Idea Collector.
• System shows trip ideas (including weblinks) captured by user
• System shows related trip ideas suggested by product.
• Ideas are generated by scraping Facebook pages of the user and friends, looking at past trips, using experts’ suggestions, and looking at attractions in the neighborhood of places the user found.
Now the storyboard envisions communication with others. This cell adds a way to invite participants in the Idea Collector Focus Area. The team may put in a user interface note to consider using an opening, a pane where the user can type names and choose people in place—no need for a separate window just because it is shown that way in the storyboard.
2. Idea Collector
• User can save a webpage to his or her Idea Collector.
• System shows trip ideas (including web links) captured by user
• System shows related trip ideas suggested by product.
• System shows participants who can see and contribute to this trip
• User can add people to the list of participants
• User can name a person to invite
• User can add a message for the invitee
• System alerts invitee on the user’s invitation
Once again, the product has to reach out beyond its own borders and interact with the larger ecosystem. Here the storyboard specifies that we send an alert to another person. That creates a new Focus Area on the user’s cell phone for receiving an alert. Note that we haven’t made any decisions yet how that alert might happen—our own app on the cell phone, text message, Facebook message or post, or plain old email. Those decisions happen later.
The storyboard cell also introduces a new Focus Area, the Invitation. This is similar to the Idea Collector in showing basic information about the trip and some suggestions. But the purpose is very different and the context of use is different—the invitee needs to evaluate the trip and decide whether they will participate. So it’s been kept as a separate place.
3. New Travel Event Alert
Purpose: Inform people of updates in their travel community
Function:
• System alerts the user when new travel events happen:
• They are invited to join a trip
• (There will be more)
Notes:
• Supports any platform—phone, tablet, full computer—and uses the native alert mechanism.
4. Invitation
Purpose: Extend an invitation to join a trip with enough attractive detail to encourage joining.
Function:
• Show inviter’s message
• Show primary location and goal
• Show top-level suggestions for other things to do
• Show proposed dates for the trip
• User can accept
• User can reject this invitation
• User can reject this invitation and any similar trips
• User can suggest dates for the trip
• User can suggest friends to join the trip
This is the way building the User Environment Design proceeds. Each storyboard is woven into the evolving User Environment Design one cell at a time. Since the storyboards were designed individually, they may envision similar or overlapping places in the product. As the team walks through the storyboard, they determine whether a cell is envisioning a new place or can reuse an existing place, extending it as necessary. The process is exactly the same when weaving in the next storyboard—some places will already exist as Focus Areas in the product, whereas others will be newly defined. The User Environment Design will evolve to support them all. In the process, it is also likely to become overly complex—so see the section on the User Environment Design Walk-through coming up. Resist defining the user interface until you see what is needed in each place in the product.
You may build the first User Environment Design with a dedicated small team to roll in each storyboard and keep the User Environment Design reasonably coherent as they go. Most often though, to involve the whole team and to move quickly, multiple sub-teams roll function and content definitions into a single paper User
This storyboard cell returns to the trip owner responding to the suggestion of a new participant. The main Focus Area supporting this cell is still the Idea Collector, but the cell suggests new function—the team has thought through the dates a little more, and the user can accept the new participant. System behavior is captured with the description of the function.
2. Idea Collector
• User can save a webpage to their Idea Collector
• System shows trip ideas (including web links) captured by user
• System shows related trip ideas suggested by product
• System shows participants who can see and contribute to this trip
• User can add people to the list of participants
• User can name a person to invite
• User can add a message for the invitee
• System alerts invitee on the user’s invitation
• System shows date of proposed trip, if any
• User can mark a suggested activity as included in trip
• User can accept a proposed invitee. System sends the invite only when accepted.
Environment Design in parallel.2 In either case we recommend that you assign a small team to own it and be primarily responsible for its coherence. Good owners might be a designer and user researcher, or a user experience designer and a product manager. This team will oversee the structure of the product as new storyboards are rolled in. They will own the documentation and final design.
The user interface and product structure
The User Environment Design, particularly when it is first being formed, is not influenced by any particular user interface plan or architecture. Too much focus on user interface detail at this point will get in the way of ensuring an overall good user experience. The drawings in the storyboard cells give designers a way to think in the concrete language most natural to them (user interface sketches), while still staying out of low-level user interface details as long as possible. Building a User Environment Design asks them to extract the implications from those drawings and represent them abstractly, as functions and content in places. The more the team goes back and forth between User Environment Design and storyboards, the more they start to consider the type of user interface that makes sense for presenting each Focus Area. Holding off on committing to a particular user interface structure and low-level user interface design will make for the best product design—and overall user experience.
Thinking in terms of Focus Areas and links tends to keep the basic work of the Focus Area in the Focus Area, rather than spreading it over several places. A good Focus Area is like a well-supplied kitchen—all the tools you need are ready to hand, organized for easy access. Design focused on the user interface encourages the designer to worry about constraints of screen real estate, interactivity, and the detailed behavior of every function; it’s easy to punt and decide to put the function on a separate screen. Design thinking with the User Environment Design takes away that excuse—if a function is part of the activities to be done in a Focus Area, it goes into the Focus Area.
Once the team has got a basic User Environment Design structure—and this will take only 2 or 3 days—they can step back and define an overall user interface approach considering the total needs of the system and the types of platforms to be supported. Then the team will define Interaction Patterns for each Focus Area considering the overall architecture. They can do this because the User Environment Design helps the team see the full structure they must design for. We discuss this in Chapter 15.
Keep the user interface sketches from the different storyboard cells that contributed to a Focus Area to give user interface designers context—they show what the team was thinking about when they developed the place. Don’t take the storyboard apart; take a picture of the relevant cell and save it in the User Environment Design with the Focus Area. These sketches are a starting point for designing the presentation of the Focus Area and may be testing out initial Interaction Patterns in the context of the story.
Then once the Interaction Patterns are created, you can document the User Environment Design, collecting together the sections that go together relative to the emerging user interface.
Seeing Product Structure
The challenge of building the product structure is one of continuously moving, between scenario and structural thinking. When rolling in the storyboards you are identifying functions and placing them in an emerging product structure. But even the most careful team will necessarily find that putting more function into the Focus Areas will cause it to get messy; the structure will simply not be clean enough for a good product. So the team must step back after rolling in the core storyboards and walk through the User Environment Design to improve its structure. Then they may roll in a few more storyboards and check structure again. Or better, they might go out and validate the product concept with paper prototypes (Chapter 17) and add more storyboards in the next round, while also redesigning the User Environment Design based on user feedback.
So seeing product structure is an important skill, supported by having an external representation. It’s too hard to look across a whole product and decide if the parts of it are coherent if you have no physical representation. But when the product is concrete in a diagram, it’s not hard to scan the purpose and existing function to find the right place for a new extension—or to decide that a new Focus Area is needed. Laying out the Focus Areas on half-sheets of paper, as in Fig. 14.6, helps you see the structure of the product.
Figure 14.6 A User Environment Design under construction. Focus Areas are on half-sheets of paper; function is listed as it is discovered while creating the first User Environment Design. Eventually the team will capture it in a document, at which point printed sheets may be used when rolling in more storyboards. While you are rolling in, it’s too hard to organize the list of functions much; do that when you enter it online.
Within each Focus Area, the list of functions, content, links, and constraints summarizes what can happen in that place. As a list, it supports checking the completeness and coherence of the Focus Area—it’s easy to scan and check against the issues raised by the user data and the storyboards. When a Focus Area gets too complex, it’s straightforward to review it and related Focus Areas. What types of people does the Focus Area support? What intents? For each Persona or identity element, is the Focus Area reasonable and relevant? You may have Focus Areas that support two disconnected intents—so you’ll split it into two. Multiple Focus Areas may overlap in function and purpose—so you’ll merge them. Through this process of examination, designers can rebalance the Focus Areas and clean up the design.
To help you see structure, be mindful of the layout of your User Environment Design (Fig. 14.7). The User Environment Design, when put online, will be a graphical model so communication design matters; the grouping of Focus Areas and their layout help the team see what the product is about. After rolling in core storyboards, organize your half-sheets of paper so you can see the sections of the product. Group Focus Areas associated with the each product concept you identified in visioning. Use the links to find Focus Areas that work together to achieve an overarching intent and put them near each other. Larger applications often have a set of Focus Areas devoted to supporting a particular intent; mobile apps tend to be more targeted to a single intent but have a larger ecosystem of apps that they are a part of.
Here is one way to approach the layout; start by laying the sheets on a large conference table or a wall. You will reveal the layers of the product, with entry areas at the top, shared utilities at the bottom, and groups of Focus Areas used for key tasks in the middle:
• Put any entry Focus Areas—starting points for particular intents—at the top; these are often overviews, provide quick information, or other places offering decision-making support.
• Look for utilities—Focus Areas providing services to a group of Focus Areas. In our travel example, the “Activity Explorer” is useful whether you’re first thinking about the trip, doing the logistics, or in the middle of the trip, so it is one of these. Put these beneath the Focus Areas they are supporting, creating a lower layer of supporting Focus Areas.
• If Focus Areas supporting different devices are significantly different, represent them as separate Focus Areas in their own mobile User Environment Design, particularly when they involve multiple Focus Areas to achieve the activity. Then the mobile team can see what they are building. Place this smaller User Environment Design to the side of the one for the main product. But be sure to check that common function is represented the same way and that you note how data is passed between the products. Smaller differences between platforms, often between a Web product and a tablet interface, can be captured by annotating a Focus Area with any differences in the tablet.
Figure 14.7 Part of a full User Environment Design after the first set of storyboards have been rolled in and it’s been put online. The layout and color show the different product concepts. The function has been organized by Interaction Pattern section as described in the next chapter.
The resulting User Environment Design diagram reveals the structure of the practice you will deliver across all the devices you are planning to support. This layout will let you check your links to ensure easy access between the Focus Areas that are used together. It will reveal whether you have committed any of the classic product design errors. Remember every Focus Area should fulfill a real intent, should forward the user’s activities by providing content, decision support, quick updates, or something that makes spending time there worthwhile—you don’t want any Focus Areas that deliver nothing except access to another Focus Area! We call that a hallway in your product. Laying out the Focus Areas in a sensible way will help you examine and normalize your product structure and sets you up for the User Environment Design Walk-through.
The User Environment Design, as the floor plan of your product, lets you see the big picture of what you are building. It shows you the places where the user will focus to achieve an intent—and because each place has a purpose, it encourages the team to bring together all the function and content needed for that intent. This implicitly builds in good principles of user experience design. The links make sure that a flow of action is supported by the right connections between places. Then laying out the places into coherent subsystems, each focused on supporting a coherent activity, lets the team see exactly what they are building. Taken together, the User Environment Design is the best way we have found to help teams thinks structurally about the product as a whole. So after rolling in the storyboards, the next step is doing the User Environment Design Walk-through to keep this structure coherent.
User Environment Design Walk-throughs
You’ve rolled a set of storyboards into the beginnings of a User Environment Design. But as we said after four to six storyboards, your User Environment Design starts to get unwieldy. Too many individual decisions have been made without an eye to the overall coherence of the product. Perhaps any individual function in a Focus Area could be justified, but taken together they suggest a different user focus that should be separated out. Two Focus Areas that started clearly distinct will, as function is added to each, start to overlap to the point that the distinction is no longer clear. Before continuing, you must ensure that you have a good backbone product structure on which to build. So now step back to do a User Environment Design Walk-through to ensure coherence and consistency of the product. Never go straight from your first User Environment Design to a user interface of the product; your first cut will be both messy and incomplete, even for an initial paper prototype made only to test the concept. Doing a walk-through is part of your ongoing design process. Clean up with a walk-through after your core storyboards are rolled in, then go out and test; come back and fix the structure, perhaps roll in more storyboards, and do another walk-through; then build a new prototype and test again. Continue this cycle until you have validated and extended the product as desired.
You’ll see additional design possibilities when you walk through your design. The design itself suggests new possibilities when you pause to inquire into it. A set of Focus Areas taken together may imply support for a whole task or additional job type like manager versus worker; three Focus Areas might be consolidated into one, addressing the fundamental intent more directly; or functions in several Focus Areas suggest an activity which could be supported directly in its own Focus Area. It’s this step of rationalizing the design against the user practice that will lead to a solid, flexible base structure that supports many different uses.
Walking the User Environment Design also gets the team into position for the next phase of design. It ensures the whole team is clear on what they have chosen to put in the product and how they think it will work to support the user. It identifies test cases—conditions or design elements which become a focus to test with users in prototypes. In this way it becomes the preparation step necessary before iterating the design with users.
To run a User Environment Design Walk-through, start by laying your Focus Areas out on a wall or table as described above, so that you can see the structure explicitly. We recommend doing the first walk-through in a one or two day face-to-face meeting. Subsequent walk-throughs after the basic structure is settled may be able to be handled remotely, with good meeting tools. Or allow the User Environment Design owners to do the walk-through and fix the structure before the next mock-up testing round.
With the User Environment Design laid out, have each member of the team walk the Focus Areas and overall structure looking for issues. Here are a set of questions to ask when checking a User Environment Design—and it’s no accident that they are similar to those which drove building it:
Are Focus Areas coherent? Does each Focus Area support one activity within the overall task? Is that represented by the title and purpose statement? Be suspicious of any Focus Area that has no written purpose. It’s often because the team isn’t clear on what the purpose is, or there are multiple activities mixed in the Focus Area. If you decide a Focus Area is too complex, split it apart to support multiple intents that may have been collected there.
Are Focus Areas distinct? Collect the Focus Areas which support the same part of the practice—the same activity, task, or job type—and compare them. Are they clearly distinct? Do they, taken together, provide coherent support for this part of the practice? Can they be recombined to improve the practice? Do you have Focus Areas that overlap in purpose—for example, multiple search boxes. Can merge them?
Do Focus Areas support real work? Is the Focus Area only a hallway, leading somewhere else with no real function of its own? All Focus Areas must deliver value in themselves. Look for Focus Areas which are really glorified selection boxes—the user is just making a selection, not doing any real work. Look for Focus Areas which group related function, or reveal data from the system, but which don’t support a coherent activity.
Are functions and content correct? Are functions in direct support of the Focus Area’s purpose? Given the practice supported in this Focus Area, are there missing functions? Is there extraneous or missing content? Is everything needed to support the intent brought into this place coherently?
Do links make sense? Do they help the user move smoothly to the next necessary action or information to support their intent? Are they missing completely, so that there is no way to get from one place to another? Do they support the activity as you designed it with storyboards?
Is your overall structure optimal? Certain patterns of links and Focus Areas always indicate trouble (see the “Classic Errors” above). Do any of these patterns appear, and do they indicate problems in the design? If you have a hard time seeing it, make a little Post-it User Environment Design with just titles, purposes, and links and look for patterns.
Is the practice supported? Finally, use the consolidated models to refresh your memory and look at the User Environment Design from the point of view of the different job types, activities, collaborations, and identity elements being supported. Does the design enhance life and work? Does the design work for each different kind of user? Does it account for the issues they care about? Run actual sequences or walk the Day-in-the-Life or Collaboration Model through the User Environment Design, asking how this user would get that real life done given the new product. See if you can make it break down.
Does the design support the Cool Concepts? Does it let the user move through their unstoppable flow of life? Will the design support accomplishing goals in small moments of time, across different devices? Which Focus Areas need to run on multiple platforms? Will they work well no matter the platform? Look back at the principles from the Cool Concepts to be sure you are supporting these core motives.
After the team members identify issues individually, the User Environment Design owner or a facilitator walks the team through resolving them in a discussion with the team. Start with the high-level box structure: where might Focus Areas be combined or split up; where is the structure hierarchical, leggy, containing hallways, or otherwise bad; where are there Focus Areas without a single, clear purpose. Resolve these issues, starting with the most important and central Focus Areas and working out.
Then look at the function, links, and content of each Focus Area. Make sure everything in a Focus Area supports its overall purpose. You may choose to split out a closely related group of function at this point, or create links you didn’t identify before. When you’re done, the User Environment Design owners clean up and document the new structure in an editor.
There will be situations where the right fix to a potential problem is a judgment call. A certain design is attractive, but will it work for the users? You’ve split a Focus Area because you believe this part of the activity is its own concern and should be supported separately. Are you right? When you have specific questions and no data to answer them, capture a test case. Write it on a list and save the list for the prototype interviews. You’ll look for opportunities to test these decisions directly when you’re validating the design with users.
Using a walk-through this way pulls the User Environment Design back together into a structure which makes the users’ practice coherent. Like a groundskeeper rethinking path layouts, the walk-through gives you a chance to step back from your design. Now you can either test it with users or extend it with more storyboards. Or, better yet, do both in parallel—the sooner you get feedback from real users on their design, the better off you are.
Seeing structure: classic errors
Exposing the database is still a problem in too many products. (In fact, frameworks such as Ruby on Rails3 positively encourage putting the database in the user interface.) Instead of understanding the practice and creating a product structure to support it, product designers simply put the data tables and relationships on the screen, one table per Focus Area, requiring the user to learn and traverse the database schema. Users don’t want to understand your database—they want to focus on their activities. And a hierarchical structure is prone to becoming hallways—a series of Focus Areas, each of which fulfills no real intent except to get to the next place.
One Central Place forces the user back and forth to a central place before going on to the next intent. One Focus Area becomes the central hub, whether or not it supports any real intent or needs to be in the center of the activity. What is the next likely thing a user wants to do after completing a step? Your user data will tell you. Provide function that lets the user get there without interrupting their flow of thought.
Legginess forces the user to traverse many places to get to the Focus Area they need. Shopping sites that move from category to category are often too leggy. Wizards can lock the user into too many steps—and are often unnecessary with proper design. Or designers, with the best of intentions, use scenario-based design and gave each task step its own Focus Area. Hierarchies can become a set of leggy hallways. Bring what the user needs into the place—don’t drive them through a set of links.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.