Review by Steve Toub (October 15, 2000)

Software for Use

Many information architects are now scrambling to get up to speed on UML, the Unified Modeling Language. UML—to vastly oversimplify—helps software developers model their development process. Information architects and their kin have found the UML approach to "use cases"—think "tasks people do while using your software, Web site, etc."—to be a valuable source of input for their design, but complain that UML is not terribly user-centric. A new mailing list, UCUML sprouted in September to discuss user-centered UML.

Software for Use is a darn good place to start to learn about user-centered use cases. Larry Constantine and Lucy Lockwood borrow ideas and syntax from the UML community yet make it much more user-centered. Their methodology, which they call usage-centered design provides a methodology and a syntax for:

  • modeling user roles
  • modeling tasks with what they call essential use cases
  • modeling interfaces
An essential use case, the keystone of the methodology, describes user intentions and system responses without describing concrete things like "screens" or "pull down menus." In contrast to conventional use cases, essential use cases model the abstract essence of the interaction, which allows for clearer thinking and therefore simpler and more innovative design.

In addition to the modeling methodology and syntax, Software for Use covers a smattering of other topics—interface design, design of help systems, usability metrics, etc. Some of these present original ideas but others rehash conventional and well-documented usability techniques. One of the most interesting ideas in the book is their Joint Essential Modeling methodology, in which users and developers jointly develop the user role and use case models. Users help create and validate the models, but do not design any interfaces.

Some of my peers who were not fluent in UML said they found the reading tough going. I confess that I didn't speak UML when I first picked up the book and I was intimidated enough by the charts and notation that I opted to hear Constantine and Lockwood in person to help me ease into the concepts. Fortunately, they have posted a slimmed down version of the core methodology on their Web site ("Structure and Style in Use Cases for User Interface Design") which also updates their thinking since the book was published. They also speak regularly at conferences and conduct their own seminars.

Quotes from the Text

On usage-centered design (p. 23):
"To design dramatically more usable tools, it is not users who must be understood, but usage—how and for what ends software tools will be employed.... Usage-centered design focuses on the work that users are trying to accomplish and on what the software will need to supply via the user interface to help them accomplish it."

On actors and user roles (p. 79):
"The concept of user role as used in this book is substantially the same as the notion of actor introduced in object-oriented software engineering, with one important difference: Actors, in the original definition, included other nonhuman systems—hardware or software—interacting with the system of interest.... Because usage-centered design is addressed to the needs of humans interacting with a system through its user interfaces, only the human players are relevant."

On use cases (p. 102-3):
"Conventional use cases typically contain too many built-in assumptions, often hidden or implicit, about the form of the user interface that is yet to be designed. As models, they lean too close toward implementation and do not stick closely enough to the problems faced by users."

On supporting evolving usage patterns (p. 267):
"The best user interfaces help novices to become intermediates and intermediates to advance toward expert usage."

On the role of users in the development process (p. 484):
"In our experience, far better results are obtained when users are intensively involved in setting requirements and in other carefully targeted activities, such as collaborative usability inspections, but are not heavily involved as participants in the actual designing of the user interface."