|| Contents:
|| 1. Development: Delivery delays. [EXPLANATION]
|| 2. Agility: The lightness of usability. [PROCESS]
|| 3. Learning: Skills transfer. [TRAINING]

= = = = =

Demand continues for public training, so we are doing it again.
The dates are 25-29 June in scenic Portsmouth, New Hampshire.
Details at <http://foruse.com/seminars/>.
= = = = =
Forward this issue to your colleagues so they can join over 1200
leading professionals who subscribe. Click here to join:
<http://foruse.com/forms/subscribe.htm>.
Browse archives: <http://foruse.com/newsletter/>.
= = = = =

1. In-Time Delivery.

We have been away a few months, but we do have excuses. Heavy client commitments (we've been helping to design the next generation of medical record-keeping systems) are part of the story. Another part of the story is our work on refining fast and light techniques for usage-centered design (see below). Tovah Beth Lockwood, born 29 March, is the rest of the story!

2. Agile Usage-Centered Design

In the last issue of this newsletter, we pointed out the controversy over the Rational Unified Process and its ability (or inability) to enhance usability through effective user interface design. A column in the November 2000 Software Development Management Forum also discussed this and other shortcomings of the unified paradigm <http://www.sdmagazine.com/articles/2000/0011/>. {You'll also find this column and others reprinted in Beyond Chaos: The Expert Edge in Managing Software Development (Addison-Wesley, 2001).]

This time around, we want to look in the other direction, toward the newly evolving lightweight processes. These include such approaches as XP or Extreme Programming, Alistair Cockburn's Crystal family of methods, SCRUM, and Pete Coad's venerable Feature-Driven Design. The lightweights are gaining in weight as more success stories and more followers accumulate. Marking their growing respectability, a confab of leading gurus in this subject matter gathered in Utah in February to sort out their differences, clarify commonalities, and unify. They did just that, forming the Agile Alliance and renaming the lightweight methods to become agile methods.

Unfortunately, user-interface design and usability are largely overlooked by the agile processes. With a couple of possible exceptions, users and user interfaces are all but ignored. Informants in the agile process community have confirmed what numerous colleagues and clients have been suggesting all along. XP and the other light methods are light on the user side of software. They seem to be at their best in applications that are not GUI-intensive.

In the midst of this usability shortfall, we have received numerous queries about usage-centered design as a lightweight method. The truth is, we have always believed processes should be as light as practical, but not lighter. We model to the extent that modeling speeds and simplifies the design, and that's it. We avoid drawing diagrams for their own sake or filling out forms for mere completeness. The core models of usage-centered design--roles, tasks, and contents--were all devised with one goal in mind: to provide "intellectual leverage," to facilitate problem solving and produce effective, innovative designs. This is where usage-centered design parts company from most of its agile compatriots. We emphasize modeling and drive the user interface design and development from the models we construct, thus ensuring the fit between user interface and the user tasks to be supported.

We never thought of ours as a lightweight process per se, nor did we set out to create such a thing. We just tried to keep things simple and to design simpler but more successful systems. Now we and our clients and colleagues are giving this matter of process weight and agility a second look. Many of us are finding that models constructed as inventories on common index cards may be as good as or better than more refined and detailed ones built as diagrams or with standard forms. Structured formats and detailed templates may be helpful for beginners and may facilitate thoroughness, especially in documentation, but for speedy design, the most compact expressions seem to work best.

In truth, the core models of usage-centered design all lend themselves to varying degrees of simplification and shortcutting. We have written about this on previous occasions, as in the note on shortcut modeling for Web design <http://foruse.com/articles/shortcuts.htm>. The important thing to keep in mind is that, at the heart of the matter, a user role model is just a collection of named user roles along with their brief descriptions. Task cases are often well-explained by their names alone and in essential form are seldom more than a handful of lines long. Well-conceived roles or tasks can easily fit on individual index cards.

Which brings us to "agile usage-centered design." Like the other agile methods, its basically a collaborative process. A mixed team of designers, developers, and users or domain experts sort out the requirements and an appropriate solution by marking and shuffling cards. Ordinary index cards serve as the medium for capturing and organizing both user roles and user tasks. Roles and tasks are brainstormed directly onto index cards. Brief descriptions for roles are added, and process narratives are written onto the task cards in essential--abstract, simplified, technology-free--form. The use of index cards forces parsimonious expression and keeps the descriptions focused and succinct. Cards are readily sorted to rank roles and tasks in order by expected frequency or importance and are easily shuffled into groups for implementation on particular release cycles.

For more detail on the critique and step-by-step on the agile usage-centered design process, see the full paper <http://foruse.com/articles/agiledesign.htm> where you will also find more references and useful links.

3. Training or Teasing.

It takes time to learn any new technique, however simple it may be. In our experience, usage-centered design requires 4 or 5 days of intensive study and hands-on application for most learners to reach the point where they can do it on their own. A week may not make them master designers, but it will give them enough to start applying the skills and techniques effectively in real-world settings.

Almost without exception, clients who initially opt for shorter introductions end up coming back for more. One-day and two-day tutorials are enough for an overview and a carefully orchestrated sampling, but not enough in most cases for much genuine training or skills transfer to take place. For these reasons, we offer public seminars that last a full week and devote a third of the time to monitored and reviewed hands-on application. (See <http://foruse.com/seminars/>.) And we always recommend that in-house training clients make the investment of the extra day or two that makes training truly payoff.

= = = =
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 2001, 2002, Constantine & Lockwood, Ltd.

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