The four interface models and the design spiral

Four people, four pictures of the same system

When an interface is analysed and designed, four different models of the system are in play at once, and they belong to different people.

The user model is the profile of the people who will actually use the system — age, physical ability, education, cultural background, motivation, goals, and how often they will use it. A common division is novices, knowledgeable but intermittent users, and knowledgeable frequent users. Personas are one way to write this model down.

The user's mental model, also called the system perception, is the picture the user carries in their head about how the thing works. It is built from whatever they have been exposed to, and it does not have to be true. It is the model that governs their behaviour anyway.

The design model is the engineer's model: the data, architecture, interface and component design that will be built. It is the only one of the four that is deliberately constructed and written down.

The implementation model is what the finished product projects — the look and feel of the interface plus every supporting artefact: onboarding, help text, error messages, the manual, the tooltip, the app-store screenshot. It is what the user learns the mental model from.

These four differ by default. Nothing keeps them aligned unless someone works at it, and that work is the interface designer's actual job. The chain that matters is this: the design model must be shaped by the user model, and the implementation model must faithfully express the design model — because if it does, the user's mental model converges on the design model and people feel that the software behaves the way they expected.

The spiral, not the pipeline

Interface analysis and design runs as a spiral with four framework activities: interface analysis and modelling, interface design, interface construction, and interface validation. Each turn of the spiral elaborates the last. Analysis profiles the users, then does task analysis — the tasks people perform to reach their goals, described and decomposed — then work-environment analysis, which asks about the physical setting: light, noise, posture, whether both hands are free. Design turns that into a set of interface objects and actions and their screen representation. Construction almost always means building a prototype, because a prototype is the only practical way to run validation at all. Validation asks three questions: does the interface let the user do every task and every variation, is it easy to learn and use, and do the users accept it as a tool worth having.

Because it is a spiral, the first pass does not have to be complete. That is a licence, not an excuse: what it buys you is the right to put something in front of a user early, when changing it is still cheap.

The thinking move

When a user does something 'wrong', do not start by asking what they misunderstood. Ask which model the implementation taught them. A confident wrong action is almost always a faithful reading of a misleading implementation model, and the defect is yours.

Worked example — the BorrowBox hold that vanished

BorrowBox reservations are holds that expire two hours after the collection window opens; after that the tool returns to the pool for someone else. The design model was explicit about this. The implementation model was not: after reserving, the app showed a green tick and a locker number, which is exactly what a shopping app shows when it has taken your money. Members formed the obvious mental model — I have bought this, it is mine, it will wait — and arrived at six o'clock to find the hold gone and a stranger's tool in the locker.

Nobody had written a bug. The design model was sound and the code implemented it correctly. The failure was that the implementation model projected a different design model from the real one, and the mental model dutifully followed. The fix was a change to the implementation model only: replace the tick with a live countdown, name it 'Hold expires in 1 h 47 m', and put the same countdown in the confirmation email. Complaints about vanishing reservations stopped without a line of reservation logic changing — which is the clearest possible demonstration that the four models are separate things.