To Constantine & Lockwood, Ltd., Home Page To Constantine & Lockwood, Ltd., Home Page
To Constantine & Lockwood, Ltd., Home Page Back to Previous Page          
forUse: The Electronic Newsletter of Usage-Centered Design
#4 | May 2000
  Subscribe. Prior IssueIndex by issue.Next Issue

|| Contents:
|| 1. Shopping: Muddled e-Commerce Metaphors
|| 2. Modeling: Modeling Multi-User Interaction
|| 3. Training: 26-30 June, Portsmouth, NH; 18-22 September, Portsmouth, NH

= = = = =

Do your colleagues a favor; forward this issue to them. They can
join over 2000 leading professionals who subscribe. To join, click
here: <>.
Browse archives: <>.
= = = = =

1. Shoddy Shopping Carts

Shopping carts on Web e-commerce sites are a disgrace to the name and a major contributor to poor "shopping experience." Imagine what shopping would be like if you went into a brick-and-mortar store where your shopping cart was kept in a separate room. To put something into the cart, you go to that room. To see what's in your cart, you go to that room, where you will be shown a clipboard with a list of the items in the cart. To take something out, you go to the room and change the number on the clipboard to zero. You will be allowed to put things into the shopping cart only at certain times or in certain places, such as after reading a sales pitch.

If you want to continue shopping, you have to return by a different route, sometimes going all the way back to the store entrance. If you attempt to take a shortcut and go around the back way, you may find that your shopping cart has been suddenly and mysteriously emptied.

This scenario may sound ridiculous, but this is precisely the way the shopping cart metaphor is realized at many sites on the Web. Silly simulations that have virtual carts careening down virtual aisles are not the answer either.

Instead of naive emulation or name-only metaphors, interaction design for e-commerce needs to draw on real-world metaphors for genuine insight into the needs and interests of users and for inspiration on efficient ways to satisfy them. For example, in real-world shopping, the shopping cart is always visible and with you, making it easy to add or remove items or to check the contents to see whether you have bought something for every niece and nephew. This argues for using a persistent cart in e-commerce, a simple idea that can improve both usability and the user experience.

For more on the use and misuse of metaphor, on and off the Web, see the new Application Note <>.

2. Modeling Multiple User interaction

The question below, recently posted to a web-based discussion group, reflects a common confusion about essential use case modeling.

[Essential use cases] seem to split things between user and system. What about situations where there are other users involved? What if it's not always a "System Response/Responsibility" that provokes a "User Action/Intention" but for some steps it's ANOTHER user's action/intention that provides the stimulus?

Offhand, I can think of a couple ways to do this, but I'm not sure which is best.

1) A 3 column layout for "User Intention", "System Responsibility" and "Other User's Responsibility"

2) Making the other user's actions a subcase or extension of System Responsibility.

Most often this kind of confusion arises because the designer is trying to model either the workflow or a business process rather than the interactive needs of users in particular roles.

There are two main variations on this all-too-easy trap, depending on whether the "other users" about whom the analyst is concerned are or are not interacting with the system being designed. In the latter case, they are not direct users but indirect users; they may be interacting with a user in some role, but not with the system.

Essential use cases model the needs of the direct or immediate users of a system not other, indirect users who may, in turn, interact with direct users. This limitation simply reflects the objective of usage-centered design: to devise a user interface that will efficiently mediate between the system and those who interact with it. Often the business process or workflow for the problem may involve a direct user who obtains information from or delivers it to other persons who do not interact with the system but only with the users of the system.

For example, a telephone order taker working in a call center would be a direct user of an order entry system. Callers on the phone may be viewed by a business analyst as part of the context of the application, but they are not direct users, since they do not have any interaction with the application itself. They do not see the screen nor can they select a field. All their interests in relation to the system are mediated by the order taker and fulfilled by the use cases supporting the order taker role. Those use cases would properly only show the user intentions of the order taker and the system responsibilities of the order entry system.

The other potentially confusing case is one in which there are various direct users of the system. This, of course, is perfectly normal; typically there are multiple users interacting with a system in various roles.

For example, a document or other online artifact created by one user might be handed off to another user who must process it further. These two groups of users represent distinct roles in relation to the software, and each will need to interact with some kind of interface that must be designed. Each of these roles will need to be supported by a collection of use cases. Thus, the first role, say the "Originator" role, will need some use cases associated with creating the document and handing it off to another user. The other role, call it "Completer," will need its own use cases associated with modifying or further processing the document. However, every use case for either role involves just the intentions of the user in that role and the corresponding system responsibilities. These intentions and responsibilities will guide the design of that part of the user interface of interest to users in the particular role.

In any case, the actions or intentions of other direct users are mediated by and represented by the system through its user interface. Thus the Originator does not "trigger" some action or intention on the part of the Completer. Either the Completer intends to work on the next document or the system has the responsibility for indicating the availability of a document for action.

Yet another source of such confusion arises from shoehorning into one use case description a scenario that spans more than one essential use case. In these situations, decomposing the use case into inclusions or extensions is usually the cleanest solution. For more on use case decomposition and the relationships among scenarios, tasks, use cases, and essential use cases, see our recent paper <> .

3. Seminars in Usage-Centered Design

The sold out Australian seminar in May was a smash success. One participant called it "The most thorough and practical course I have ever attended."

Now the June seminars in Portsmouth, NH are nearly sold out.

Another series is planned for New England on 18-22 September. Details are available at <>.

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

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

  Subscribe. Prior IssueIndex by issue.Next Issue