| |
|
|
|
|
|
|
|
|
Excerpted from Designing From Both Sides of the Screen By Ellen Isaacs and Alan Walendowski Now the fun part begins. You've got your list of requirements and you need to turn it into a user interface design. In this chapter, Ellen explains how to do that. ... Start with Tasks To decide how to design the system, you need to think in terms of the users' tasks. You aren't trying to figure out where to put the features, you're trying to figure out how to help people accomplish tasks. So start with a copy of the Task List, this time rearranged to reflect the priorities you agreed on when reordering the Functional Requirements Document. The prioritized Task List for Hubbub is shown in Figure 6.1.
The prioritized list reminds you to focus on making the higher priority tasks as simple and easy to accomplish as possible, if necessary at the expense of lower-priority items. However, the priority of the tasks was determined by many factors, only some of which are relevant to the user interface design. What you really want to know is how important each task is to the users as they accomplish their goals. To determine this, think about the tasks along two independent dimensions:
If you combine those two dimensions, you get four categories:
Now assign each of your tasks to one of these categories. You'll have to use your judgment, again based on your analysis of user behavior during the initial phase of the project. The reason to categorize the tasks is that the tasks in each of these categories should be designed differently, as we'll illustrate shortly. First, let's explore these levels of priorities by looking at the Hubbub Task List reorganized into the four categories, shown in Figure 6.2. I didn't want to lose the overall priority, so I've indicated by [color] which ones are Core, Important, and Nice to Have. As you can see, they are related but not completely correlated. In particular, the Core tasks should fall mainly in the Frequent by Many category, the Important tasks should fall primarily in Frequent by Few and Occasional by Many, and the Nice to Have may be scattered among all the categories, but primarily in the latter three.
The Frequent by Many category is the most important. These are the tasks that nearly everyone will do nearly every time they use the application. For Hubbub, that includes checking to see who's around, hearing people coming and going in the background, and sending and receiving text and sound messages, all Core functionality. We don't think we have to show who is messaging with whom in the first release (it's a Nice to Have feature), but if we do, it's the type of activity many people will do often. You should spend most of your effort making sure that users can accomplish these all-the-time tasks smoothly and easily, without any breaks in flow. If people have trouble with these tasks, they won't like using your application. Some tasks are performed all the time, but only by some people (Frequent by Few). In the case of Hubbub, our initial investigations indicated that some people will use Hubbub from multiple locations while others will use it from just one, so features related to multiple sites are Frequent by Few. Also, we found that some people carry on conversations with different people at the same time, whereas others don't like to multitask like that and will engage in only one conversation at a time, so features related to carrying on multiple conversations also fall into this category. Other tasks are needed by everyone, but only occasionally (Occasional by Many). Good examples are installation and setup . Everyone has to do them, but they do them only once or twice. In Hubbub, everyone needs to add bubs, but they usually do so once at the beginning and then only occasionally as they encounter more people to add. Once they have enough bubs, they'll want to put them in groups or order them. (We're figuring we'll only have to do one of these features, not both.) And it should happen only occasionally that people have multiperson interactions, turning their instant messages into chat sessions. Finally, there are some tasks that few people use and even then, only rarely. This category (Occasional by Few) should consist only of tasks that you can't not provide. For example, if people can add a bub, they must be able to remove that bub, even if few ever will. Many privacy and security features fall into this category. Few people ever turn on privacy features, but they need to know that the features are available or they won't use the application. Help features also may be in Occasional by Few — you need them for those who seek them out, but most people don't. If you have any tasks in this list that are not strictly necessary, you should convince yourself that they're worth the time and effort to build if few people will ever use them. In the case of Hubbub, most of the Occasional by Few features are of this "must have" nature, but we do have a few nonessential features that enable users to create new sound messages, import them, and send them to others. We justify these on the basis that they allow the few avid users to create a better experience for everyone else. If just a small group of people become excited about creating their own sounds, they'll send them to their bubs, who will send them on to others, and soon enough, many people's experience will be enhanced by the efforts of a few. However, those features are Nice to Have, so even though we keep them on the list, we're not likely to get to them in the first release unless we find from the usage study that there's a strong desire for them.
Map Priorities to Design Now let's see how dividing the tasks into these four categories helps you design the interface. Each of the two dimensions maps to a different UI treatment:
These two rules tell us how to handle the four categories. Frequent by Many tasks should be visible and take a minimum of steps. Frequent by Few tasks should require a minimum of steps for those who use them all the time but can be suggested on the main screen or hidden so they don't clutter everyone's screen. Occasional by Many tasks can take more steps if necessary but they should be easy to find — they're not worth a lot of prime real estate, but you should be able to look at the main screen and have a good idea how to get started. Occasional by Few tasks should be hidden and might require more steps:
Of course, you'd like all your tasks to be visible and require few steps, but that's not possible for any but the simplest application. You're going to have to make tradeoffs, and this diagram is intended to help you determine the best way to make them. Keep in mind that the Frequency by Commonality guideline is just that. Sometimes you will be faced with other considerations when deciding how to handle a feature. But the guideline should serve as a helpful heuristic that applies in the majority of cases. (When I discuss the process of laying out Hubbub in Chapter 7, I'll explain how the Mute option was a case in which I made an exception to this guideline.)
Example: "Reverse Designing" Priorities Let's get concrete. For the moment, we'll step away from Hubbub so we can compare two designs based on the same set of requirements: the Palm Date Book and Microsoft Outlook Calendar. What are some of the Frequent by Many tasks that most people do most of the time when they use a calendar? Palm's Date Book's design (shown in Figure 6.3) treats the task of making a one-hour appointment for sometime this week as Frequent by Many. How can I tell? Let's look at what's involved in this task. When you turn on the Date Book, you see today's appointments, with one line for each hour. To add an appointment today, you tap the line by that hour and type the name — two clicks. (We count entering one text entry as one "click" since it's one mental event and users are in control of how much they enter.) If the appointment is on another day this week, you first tap that day, then the hour, and then type — three clicks. Even though the screen is relatively uncluttered, those two tasks are easily visible and they take few clicks. Making an appointment next week takes just one more tap to scroll the week. The scroll arrows are visible (suggesting the feature), but next week is hidden, so it is treated as an Occasional by Many task.
On the other hand, Outlook Calendar (shown in Figure 6.4) is optimized to make half-hour appointments for some time during the next two months. If you're making a half-hour appointment today, you click on the time slot and type, the same two steps that the Palm requires (plus switching from the mouse to the keyboard). If you're making an appointment for any other day this or next month, it takes just one more click to first select that date, for a total of three clicks. Certainly three clicks is nice if you happen to be making a half-hour appointment for five weeks out. But we're guessing that few people do so on a regular basis, and the cost is the visual complexity of showing not one full month but two, which makes it harder to zero in on, say, tomorrow.
Let's look at how Outlook handles making a one-hour appointment for sometime this week. The quickest way is to click and drag to select one hour, and then type. Yes, it's just one more click than the Palm, but that extra drag and release costs most people extra effort every time they make a one-hour appointment. Perhaps Microsoft had data indicating that most people make half-hour appointments far more often than they make one-hour ones, but our experience indicates that the opposite is true. Yet making one-hour appointments not only requires extra physical effort and more manual dexterity, it also requires mental effort to figure out the drag shortcut. This shortcut is typical of the kind offered for Frequent by Few tasks: Once you figure it out, it's quick, but you need to be more motivated to figure it out. We suspect many people don't figure out this drag-select option, and instead use the standard method of double-clicking on the first half-hour to launch a huge popup cluttered with menus, buttons, tabs, and other widgets, shown in Figure 6.5. From there you enter the appointment name and change the end time using a pull-down menu. Using this method, it takes five steps and two mode switches to create a one-hour appointment, indicating that it is considered an Occasional by Many task.
Why did the Outlook designers choose this approach? My guess is because this design is more flexible. It's just as easy to make an appointment for one hour as it is to make one for 1.5 hours, 2 hours, or even two days, all of which are just a little more work than a half-hour. But everyone pays the price for that flexibility every time they make a one-hour appointment because they have to drag and select.* Palm's Date Book sacrifices the half-hour task in favor of the one-hour one. To make appointments for more or less than an hour, it takes a lot more work. First you tap the start time to view a time editor (see Figure 6.6), then you tap the end time, then you tap once or twice more to adjust the end time, tap the OK button, and finally type your appointment. That method takes five or six steps to create a non-one-hour appointment, about the same as the standard Outlook method for creating non-half-hour appointments, and with far less clutter.
These examples show how your priorities will be reflected directly in your design. You can even "reverse design" an application to figure out the priorities of the designers. Whether you plan it or not, fast, obvious tasks imply that you expect most people to do them all the time; fast, less obvious tasks indicate that you expect only some people to do them frequently; slower, more obvious tasks indicate that you expect most people to do them occasionally; and slower, hidden tasks imply that you expect few people to do them and only rarely. If you understand how to prioritize your tasks and reflect them in the design, it will be easier to design your application to behave like a butler.
Once you put your tasks into your Frequency by Commonality categories, show the list to the rest of the team and make clear the design implications for each category. This is an important list to get right and to agree on as a team. Discussing what goes where helps everyone think about the application from the user's standpoint and sets everyone's expectations about the UI. It also gives everyone a common basis for evaluating how well the user interface is doing its job. Later, when someone (possibly even you) wants to add a new feature because someone might want to use it sometimes, the list will show you that it belongs in the Occasional by Few category, which tells you that it may not be worth doing. (If you do decide to do it anyway, you know it should be hidden and can take more steps to complete.) Or maybe once you see people using your system you'll discover that some people are using it differently than you expected, so maybe it's time to add a requirement to support that activity and design it as a Frequent by Few task. As you design more interfaces, you should find yourself thinking in terms of frequency and commonality all the time. Even then, it's worth creating the Frequency by Commonality Task List as a useful communication tool for your team. * One way to be more cooperative would be to default appointments started on the hour to one hour, but appointments started on the half-hour to 30 minutes, especially if there is another appointment already scheduled starting at the next hour. You would need to observe real calendar use to decide whether this would be more helpful than bothersome, but it might be a good idea for a widgetless feature. (Thanks to Leysia Palen for this idea.) (continued...)
|
(c) 2002 Ellen Isaacs and Alan Walendowski
