Foundations
Usage-centered design starts with intended use.
The book's central move is to design software from the structure of meaningful use: who participates, what they are trying to accomplish, and what the system must provide in response.
Usage-Centered Design
Usage-centered design is a method for designing interactive software around user intentions and usage patterns. It emphasizes formal but lightweight models that can be inspected, discussed, and translated into interface decisions.
The stance differs from purely demographic user description. The team asks what a participant is responsible for, what successful use looks like, and what interaction structure would support skilled performance.
Practical rule
Do not begin by asking which screens to build. Begin by asking which roles need to accomplish which essential tasks, then derive the screens from that model.
Essential Modeling
An essential model describes the nature of a task without committing to a particular interface, workflow detail, device, or data-entry control. It keeps the design conversation at the level of intention and responsibility.
| Concrete statement | Essential statement | Why the second is stronger early on |
|---|---|---|
| User clicks the Add Customer button. | User identifies a new customer to register. | It leaves room for command bars, inline creation, imports, voice input, or future devices. |
| System opens a modal dialog. | System collects required customer identity data. | It states the system responsibility without prescribing a screen pattern. |
| User selects Save. | User confirms the registration is complete. | It captures intention, validation needs, and completion criteria. |
The Model Stack
The book's method can be read as a chain of models. Each model narrows design freedom only after it has made the relevant design problem clearer.
- Role model: who participates and what each role is responsible for.
- Essential use-case model: what those roles intend to accomplish and what the system owes them.
- Task model: how use cases relate, repeat, branch, and compete for priority.
- Interaction architecture: how the system organizes workspaces, objects, commands, navigation, and feedback.
- Abstract prototype: a low-detail interface representation that tests structure before visual finish.
When The Approach Helps
Complex operational systems
Role and task models are especially useful when software supports specialized work, frequent use, multiple permissions, or high consequence decisions.
Requirements ambiguity
Essential models let teams discuss what must happen without getting trapped in premature debates about screen furniture.
Large teams
Traceable models give product, design, engineering, QA, and domain experts a common object of review.
Long-lived products
A model gives later changes a place to land. Teams can ask whether a new feature is a new role, a new task, or a variant of an existing one.