|| Contents:
|| 1. Constructing Cases: Filling in blanks. [TECHNIQUE]
|| 2. Visibility: Missing metaphors. [DESIGN]
|| 3. Canon Law: Faster paper prototyping. [TECHNIQUE]
|| 4. Events: Upcoming presentations & tutorials [LEARNING]

= = = = =

Do your colleagues a favor: forward this issue to them. They can
join over 2000 leading professionals who subscribe. To join, click
here: <http://foruse.com/forms/subscribe.htm>.
Browse archives: <http://foruse.com/newsletter/>.
= = = = =

1. Use Cases: Filling in from the middle out

Essential use cases are rapidly becoming the preferred way to model tasks for user interface design. From the mail and email correspondence we receive, many companies have been finding our structured use case templates or variations on them helpful. In fact, more than 25,000 copies of the .PDF files have been downloaded from our web site. (You'll find the newly revised version for use cases and user roles at <http://foruse.com/publications/templates/> .) These paper-based forms provide a simple logical format for capturing and organizing information on user tasks, with sections for identification, for relationships with other use cases, and for describing the process or "flow of events" that actually defines the use case.

In task modeling with essential use cases, the defining process takes the form of a two-part narrative describing user intentions and system responsibilities. Ahead of the main flow of the narrative, we identify preconditions and asynchronous extensions. Asynchronous extensions are other alternative use cases that could occur at any point in the course of the narrative. To wrap up the process narrative, post-conditions are noted along with whatever business rules might apply to the use case as a whole.

In our own work, we concentrate first on the most important stuff: the name of the use case, its purpose, and the user intentions and system responsibilities that define what it is really about. In coaching and reviewing the work of other design teams, we have found that it is all too easy for people to get hung up on the preliminaries--struggling to fill in the relationships with other use cases, arguing about the right preconditions, or trying to identify exceptions in the form of extensions before it is even known what they are exceptions to!

In our experience, the whole process goes a lot faster if you build the description from the middle out rather than from the top down. Once you have defined the use case narrative--the sequence of user intentions and system responsibilities--it becomes much clearer what are the required preconditions and what extensions represent potential interruptions to the usual exchange. Often times, preconditions, extensions, and the relationships with other use cases start to become clear only after additional use cases are modeled.

To avoid spinning your wheels in task modeling, the trick is to work quickly. Once you have an overview identifying all or most of the needed use cases, start to fill in the essentials of these use cases, starting with the core of the process narrative. Work out the user intentions and systems responsibilities for a core set of use cases before worrying too much about details. Then, go back and begin to fill in more of the details and interrelationships among use cases as these become clearer. The structured forms will serve to highlight the information you ultimately need to complete, but you do not have to start out by trying to fill in every blank in order.

2. Missing Metaphors: Visual design without visibility.

Regular newsletter readers and visitors to our Web site know something about our assessment of metaphors and their contribution to usability in e-commerce and elsewhere (for our take on sham shopping carts, see <http://foruse.com/articles/metahor.htm>).

We recently encountered a new twist on the misuse of metaphors in web design: the metaphor that isn't there. Our usability inspections for one client had highlighted a problem with an information display that was awkward and confusing to users. Even worse, a part of the page that featured a novel and powerful scheme for highlighting the relationships among displayed results was too easily missed or ignored. Many viewers never did figure out what it meant or how to interpret it.

When we discussed the problem and our proposed redesign with the original information architects for the site, they defended their design with impeccable logic. They had designed it based on a metaphor: the metaphor of a television with a remote control. One part of the page was imagined as the television screen, where everything happened, and another part was the remote, where the user controlled what appeared on the television. Unfortunately, the metaphor existed only in the minds of the designers, not in the visible page and certainly not in the minds of users. What the information architects thought of as the remote control looked to everyone else like a simple list of items, and the supposed screen looked like no TV ever seen on this planet.

Their design decisions had all been guided by the metaphor of the imaginary TV-remote, a metaphor that was completely invisible to the user. Too bad they weren't familiar with usage-centered design. The structure principle states that the user interface should be organized on the basis of clear and consistent models that are recognizable and apparent to users. If the user can't see the model, it can't help them understand the interface or the logic behind the design.

In this case, the TV metaphor was a complete malapropism unrelated to what users were interested in or were doing. Had the page been made to look like a television screen and remote control, it would have gone from awkward and confusing to laughably awkward and confusing.

3. Constructing by the Canon

In forUse #5-6, we introduced canonical prototypes, a revised form of content model for helping to bridge the gap between a task model and a completed visual and interaction design. A canonical prototype is neither as abstract as the content models described in our book, Software for Use, nor as concrete as a "traditional" paper prototype. It splits the difference by representing the contents and organization of a user interface using a standardized set of abstract interface components, such as "collection," "notification," or "selection." You'll find more details in the original white paper <http://foruse.com/articles/canonical.htm>.

We have been delighted to get feedback from designers who have used canonical prototypes or tried similar approaches, and we are learning some tricks about how to make the abstract modeling process even smoother and more efficient.

One trick is to begin with the most abstract description, then gradually refine it and fill in the specifics so it evolves toward a progressively more concrete design. The steps in the process are:

1. Identify and list contents in abstract, generic form.

2. Transform generic components to canonical ones where possible.

3. Map overall layout with boundaries around component extents.

The first thing is to map out all the contents of the interaction context or view being designed--the tools and materials that must be provided to support the user's tasks. Initially, these might be abstract components, such as "Video clips" or "Video viewer," without regard for their appearance or how they will be realized. The important thing is not to get stalled at the outset trying to figure out which is exactly the right canonical component from among the more than a dozen possibilities. Once all the contents have been identified and noted on sticky-notes or in a list, they can be classified into canonical form as standardized tools and materials. Finally, the general layout of the interface can be worked out by grouping and positioning canonical components within the view and drawing boundaries to show how much of the available screen real estate will be occupied by each component or set of components.

At this point, the abstract prototype begins to look progressively more like a realistic design. From this form, the transition to an initial sketch or paper prototype should be relatively straightforward.

4. Learning Events: UI2001, SD2000East, OOPSLA2000

In Boston, we will do an encore of our all-day hands-on tutorial on innovation, "Inventing Interfaces," at User Interface 2001, 1 November; We'll be speaking on "Instructive Interaction" the day before. Details at <http://www.uie.com/>. (Mention code 150LC1000 and get a $150 discount!) The same week, we have an all-day tutorial on Web Design for Use at Software Development 2000 East in Washington, DC., along with a short presentation on crunch-mode design. Check out <http://www.sdexpo.com/>. We also join with Consulting Associate, James Nobel for a half-day tutorial on usage-centered design on 17 October 2001 at OOPSLA 2000 in Minneapolis <http://oopsla.acm.org/>.

= = = =
forUse is published 9 times a year by Constantine & Lockwood, Ltd., trainers, consultants, and innovators in usage-centered design. On the Web at <http://foruse.com/>. © Copyright 2000, 2002, Constantine & Lockwood, Ltd.

To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <mailto:unsubscribe@foruse.com>