Systems need to be usable. If people can't use systems we design, they will avoid, circumvent, disparage, and sabotage them.
In the good old days of computing, people were so pathetically thankful to have any kind of computer system at all that they were quite happy to wait in long queues, pick up printouts several days after their jobs were submitted, type programs on chicklet keyboards, and do all sorts of stupid stuff. Unfortunately for us development types, these days are over. In an increasingly large number of systems, the usability of a system is paramount: If you build it, they won't come if they can't use it.
This lesson has been writ large recently following the failures of several high-profile internet commerce web sites -- if the site isn't usable, no-one will use it. But it holds true even for administrative systems established by government departments or large corporations or consumer and embedded systems: if using the system requires a lot of effort, the people who need to use it will find some other way of achieving their goals, often at your expense.
The discipline of Usage-Centred Design has been introduced to incorporate usability into software engineering development processes. Described in Constantine & Lockwood's Software for Use [8], Usage Centred Design is based on essential use cases, and draws from ideas from object-oriented methodology [11, 15, 7, 2] as well as task analysis and prototyping techniques common to human-computer interaction designers. A key feature of Usage-Centred Design is that the design practitioner acts as an advocate for users, ensuring concern for usability is maintained throughout the development cycle.
Essential use cases are quite stylised, and writing good essential use cases is somewhat of a secret art. This paper casts the basics of writing essential use cases into the pattern form. The patterns are divided into two groups. The first group is presented in full detail and consists of six basic patterns. The first four patterns describe how to identify the actors in a system, and find and prioritise use cases. The next two patterns describe how to write dialogues for each use case, and how to check those dialogues using roleplays. Figure 1 summarises the problems dealt with by this collection of patterns, and the solutions they provide. In the interests of space, only the bare bones of the second group of patterns are presented. These cover the mechanics of writing essential use cases, organising them, and finding them.
The content of these patterns is not novel, rather, this paper is an attempt to cast some of the techniques of Usage-Centred Design (drawn particularly from Software for Use) into a pattern form.
Figure 1: Summary of the Patterns
Figure 2: The beginnings of a pattern language. The arrows show
the uses relationship between patterns. Usable System
represents the whole set of patterns.