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."