Implementation, Mental, and Represented Models

Key ideas#

Three models#

The About Face authors build on Donald Norman’s earlier terminology and name three models:

Implementation model: how the program really works, with its algorithms, data structures and code modules. For a film projector, it is the lamp, the shutter and the frames per second.
Mental model (also called the conceptual model): the user’s simplified idea of how it works. It need not be accurate, only useful. Many people think of the screen as the heart of the computer because that is what they look at. Technically wrong, and irrelevant for using it.
Represented model: how the designer chooses to show the program’s workings to the user. It is the only one of the three fully under the designer’s control.

A physical example from the book: pressing the brake pedal, a driver imagines a lever pressing against the wheel, while in reality hydraulics and brake pads do the work. The simplified picture is more useful in daily driving than the accurate one.

The main principle#

The user interface should follow the user’s mental model, not the implementation model. The closer the represented model is to the mental model, the easier the program is to use. The closer it is to the implementation, the harder it gets, because the mental model almost always differs from the implementation.

Why the gap is ignored#

Mirroring the implementation is much easier to build: one button per function, one field per data item, one dialog per code module. It looks logical to an engineer, but it does not help users reach their goals. And engineers who know their system in detail have made the implementation their own mental model, so it feels natural to them.

The authors’ positive example is Adobe Photoshop’s Variations dialog. Instead of numeric color fields, it shows thumbnails with different color balances. Artists think in visual results, not numbers, and the dialog follows that.

The gap is widest for technologies with no physical-world equivalent; the book mentions digital audio editing and image effects such as morphing. Users have no ready mental model there, so the represented model needs especially careful design.

How to apply it#

Elicit the mental model, not just the data. In interviews and observation, note users’ words, how they group things, and what “done”, “waiting” or “ready” mean to them. Record the terms in the glossary.
Keep two vocabularies apart. Data models and state machines describe the implementation. Requirements for screens and messages should use the user’s terms and groupings.
Spot implementation leaks in prototypes. Typical signs: one screen per database table, one field per column, internal codes or IDs shown to users, steps that mirror the back-end processing order, and error messages that name system components.
Design the represented model explicitly. For complex states, write down how they will be presented: which internal states merge into one visible state, and what the user can do in each.
Test with users, not builders. Developers and long-serving subject-matter experts share the implementation view. Check the prototype with people who don’t.

Review checklist#

Screen labels and statuses use the users’ words.
No internal codes, table names or technical IDs appear unless users work with them.
Screen structure follows users’ tasks, not the database structure.
Each visible state tells the user what it means and what happens next.
Someone outside the build team checked the prototype.

Example#

At The Workshop, a fictional chain of bike-repair workshops, the work-order entity has eight statuses: created, diagnosis, parts pending, in progress, quality check, ready, invoiced and closed. A separate parts-order entity has its own statuses. The first notification prototype simply sends each status name to the customer.

Interviews show that the customer’s mental model comes down to three questions. Have they looked at it? When can I collect it? How much will it cost? The analyst writes a represented model with three customer-facing stages (checked in, being repaired, ready for collection), each showing an expected-ready date and a price estimate. “Parts pending” never appears as such. The customer sees a changed date with a plain reason instead: “Waiting for a part, new date Thursday.” The eight internal statuses stay where they belong, in the mechanics’ interface and the data model.

Pitfalls#

Treating an accurate model as a good one → a useful simplification beats technical truth.
Letting the database schema drive the list of screens → start from tasks and from how users group concepts.
Asking only experts who know the system’s internals to approve the UI → add users who don’t.

Sources and further reading#

A. Cooper, R. Reimann, D. Cronin. About Face 3: The Essentials of Interaction Design. Wiley, 2007, ch. 2.