Mental models and interaction design principles

Lessons 2 and 3 described the human as a perceiver and a mover. This lesson describes the human as an interpreter: someone who forms beliefs about how a system works, plans actions based on those beliefs, and judges from the system's responses whether the plan succeeded. When beliefs and system match, interaction feels effortless; when they diverge, users make errors, get lost or give up. The lesson covers Donald Norman's account of action and its gulfs, the vocabulary of affordances, signifiers, mappings, feedback and constraints, the psychology of human error, and two widely used sets of design principles, Nielsen's ten usability heuristics and Shneiderman's eight golden rules. It ends with a computing scientist's tool: modeling an interface as a state machine and checking it automatically.

Mental models and conceptual models

A mental model is a person's internal representation of how something works. It is usually incomplete, sometimes wrong and always simpler than the real system, but it is what people use to predict what their actions will do. Norman distinguishes three models. The designer's model is the designer's conception of the system. The system image is everything the system presents: its interface, behavior, documentation and packaging. The user's model is what the user builds from the system image. The designer cannot talk to the user directly; communication happens only through the system image. If the system image does not make the designer's model visible, users will build a different model, and the designer will be surprised by their 'errors'.

A classic example is the household thermostat. Many people believe that turning a thermostat higher makes a room heat up faster, as if it were a valve controlling the flow of heat. Most thermostats are on–off switches: the furnace runs at full output until the set temperature is reached. The valve model leads people to overshoot the setting and waste energy. Similar mismatches abound in software: users who believe that closing an app saves their work, that a sync service keeps one copy of a file rather than several, or that a trip planner's 'arrive by' time is a departure time.

A designer's job is therefore to choose a good conceptual model, a simplified explanation of the system that users can learn, and to make it visible. Good conceptual models often borrow from familiar domains through metaphor: the desktop, folders and the trash can; the shopping cart; the playlist. Metaphors help early learning but can mislead when the system departs from them, as when dragging a disk icon to the trash on early Macintosh computers ejected the disk instead of erasing it. In RideLine, the redesign team chose the conceptual model of a wallet holding fare products: passes and tickets appear as cards in a wallet, each with a visible validity period, replacing an old model in which purchases appeared only as entries in a transaction history.

The seven stages of action and the two gulfs

Norman describes action as a cycle with seven stages. The user forms a goal. Then, on the execution side, they form an intention (plan), specify an action sequence, and perform it. On the evaluation side, they perceive the state of the world, interpret it, and compare it with the goal. Between the user and the system lie two gulfs. The gulf of execution is the gap between what the user wants to do and the actions the system allows: how hard is it to figure out how to do what I want? The gulf of evaluation is the gap between the system's state and the user's ability to perceive and interpret it: can I tell what happened and whether I succeeded?

Design bridges the gulf of execution with clear signifiers, sensible mappings, constraints and a visible conceptual model, and bridges the gulf of evaluation with feedback and a visible system state. The framework is also a diagnostic tool. When observing a usability test (lesson 9), it helps to ask at each stumble which stage failed. Did the user not know what was possible (forming the intention)? Know what they wanted but not how (specifying the action)? Fail to notice the result (perceiving)? Misread it (interpreting)? Each failure suggests a different fix.

Affordances, signifiers, mapping, feedback and constraints

The psychologist James Gibson coined affordance for the action possibilities that an environment offers an animal: a flat, rigid surface affords standing; a handle affords grasping. Norman brought the term to design in 1988, and it became so widely misused, as a synonym for 'visual cue', that in 2013 he introduced signifier for the perceivable indication of where and how to act. An affordance is a relationship between object and person; a signifier communicates it. A screen affords tapping almost anywhere; a raised, labeled button shape is a signifier that tapping there does something. Flat design trends that removed shadows and borders from buttons weakened signifiers, and studies by the Nielsen Norman Group found users took longer to find clickable elements on flat interfaces with weak signifiers.

Mapping is the relationship between controls and their effects. Natural mappings exploit spatial analogy or cultural convention: a cooktop whose knobs are laid out like its burners needs no labels; one with four knobs in a row next to a two-by-two grid of burners invites errors. In software, scroll direction, slider orientation and the position of 'next' and 'back' buttons are mappings. Feedback is information about the result of an action, and it must be immediate (within about 100 milliseconds for direct manipulation), informative and proportionate: too little and users repeat actions, such as pressing a 'Pay' button twice; too much and important feedback drowns in noise. Constraints limit the actions possible: physical constraints (a USB-C plug fits either way up, removing a constraint that users got wrong), logical constraints (a date picker that grays out past dates), semantic and cultural constraints. Good constraints prevent errors before they happen.

Consistency underlies all of these. Internal consistency means the same action means the same thing everywhere in a product; external consistency means following platform conventions so that knowledge transfers from other apps. Apple's Human Interface Guidelines, Google's Material Design and the Windows design guidelines encode external conventions for their platforms. Breaking convention sometimes pays, but the burden of proof is on the designer.

Human error

James Reason's work on human error, developed from studies of industrial accidents, distinguishes errors by their place in the action cycle. Slips occur when the intention is right but the execution goes wrong: pressing the adjacent button, typing a word from a habitual sequence (a capture error), or forgetting a step after an interruption. Lapses are memory failures, such as leaving the original in the photocopier. Mistakes occur when the intention itself is wrong because of a faulty mental model or rule: a rider buys a zone 1 fare for a trip that crosses into zone 2 because they misunderstand the zone map. Mode errors, where the same action does different things in different modes, are a notorious slip: typing text while the editor is in command mode, or entering a dose in milliliters per hour on a pump that is set to milliliters.

The design response differs by type. Slips are reduced by spacing and sizing targets well (Fitts's law), avoiding modes or making them highly visible, avoiding similar-looking actions with very different consequences, and making destructive actions reversible. Mistakes are reduced by better conceptual models, clearer information at the point of decision (show which zones a trip crosses before payment) and constraints that prevent invalid choices. In every case, the system should help users recognize, diagnose and recover from errors, with messages that say what happened in plain language, why, and how to fix it. Reason's Swiss cheese model, in which accidents occur when holes in several layers of defense line up, reminds designers that blaming the last person in the chain, the user, rarely fixes anything.

Nielsen's ten usability heuristics

In 1990 Jakob Nielsen and Rolf Molich proposed a short list of usability principles to guide inspection; Nielsen refined it in 1994 by analyzing a large set of usability problems, producing ten heuristics that remain the most widely used checklist in the field. They are used for heuristic evaluation in lesson 8.

Shneiderman's eight golden rules

Ben Shneiderman's eight golden rules of interface design, from his textbook Designing the User Interface (first edition 1987), overlap heavily with Nielsen's list but frame them as rules for designers. Strive for consistency. Seek universal usability (design for novices and experts, diverse abilities and contexts). Offer informative feedback. Design dialogs to yield closure: organize sequences of actions into groups with a beginning, middle and end, so that users get the satisfaction and relief of completion, as when a receipt ends a purchase. Prevent errors. Permit easy reversal of actions. Keep users in control. Reduce short-term memory load. Shneiderman also championed direct manipulation: continuous representation of objects of interest, physical actions (dragging, pinching) instead of complex syntax, and rapid, incremental, reversible operations whose effects are immediately visible. Direct manipulation narrows both gulfs at once, because the action is the object and the feedback is the object changing.

No list of principles is complete, and principles conflict: minimalist design (heuristic 8) can hide options that recognition (heuristic 6) wants visible; flexibility for experts can undermine consistency for novices. Principles are tools for generating and critiquing designs, not rules that guarantee usability. Their value is in giving teams a shared vocabulary for problems and in catching common mistakes cheaply.

Checking an interface as a state machine

Computing scientists can check some principles mechanically. An interface's navigation can be modeled as a finite state machine whose states are screens (or dialog states) and whose transitions are user actions. Graph algorithms then answer questions directly: Is every screen reachable? Can the user always get back to a safe state (user control and freedom)? Which screens lack an exit? How many actions does the shortest path to each goal take, a crude measure of efficiency? Researchers such as Harold Thimbleby have used such models to find serious problems in medical devices, including infusion pumps whose number entry and mode logic allowed dangerous sequences. The program below applies the idea to RideLine's old purchase flow.

# Treating an interface as a state machine: check the RideLine fare-purchase flow for
# unreachable screens, dead ends (no way back or forward), and missing escape routes,
# and compute the fewest actions from Home to every screen with breadth-first search.
from collections import deque
flow = {
    "Home":        {"buy fare": "ChooseFare", "plan trip": "Planner", "menu": "Menu"},
    "Menu":        {"fares": "ChooseFare", "account": "Account", "back": "Home"},
    "ChooseFare":  {"pick pass": "Quantity", "back": "Home"},
    "Quantity":    {"next": "Payment", "back": "ChooseFare"},
    "Payment":     {"pay": "Processing"},                    # no back or cancel here
    "Processing":  {"ok": "Receipt", "declined": "PayError"},
    "PayError":    {"retry": "Payment"},                     # cannot leave except by retrying
    "Receipt":     {"done": "Home", "add to wallet": "Wallet"},
    "Wallet":      {"done": "Home"},
    "Planner":     {"back": "Home"},
    "Account":     {"back": "Menu"},
    "OldPromo":    {"back": "Home"},                         # left over from a past campaign
}
def bfs(start):
    dist = {start: 0}; q = deque([start])
    while q:
        s = q.popleft()
        for t in flow[s].values():
            if t not in dist:
                dist[t] = dist[s] + 1; q.append(t)
    return dist
d = bfs("Home")
print("fewest actions from Home:", {s: d[s] for s in flow if s in d})
print("unreachable screens:", [s for s in flow if s not in d])
print("screens with no way back toward Home:",
      [s for s in flow if s != "Home" and "Home" not in bfs(s)])
escape = {"back", "cancel", "done"}
print("screens with no back, cancel or done action:", [s for s, acts in flow.items() if s != "Home" and not escape & set(acts)])

fewest actions from Home: {'Home': 0, 'Menu': 1, 'ChooseFare': 1, 'Quantity': 2, 'Payment': 3, 'Processing': 4, 'PayError': 5, 'Receipt': 5, 'Wallet': 6, 'Planner': 1, 'Account': 2}
unreachable screens: ['OldPromo']
screens with no way back toward Home: []
screens with no back, cancel or done action: ['Payment', 'Processing', 'PayError']

The analysis finds a leftover promotion screen that no transition reaches, and it finds that the payment, processing and payment-error screens offer no cancel or back action. Every screen can eventually reach Home, but only by going forward: a rider who changes their mind at the payment screen has no way out except to pay, and a rider whose card is declined can only retry, violations of user control and freedom. (A processing screen without cancel may be acceptable for a few seconds, but it should time out to an error with an exit.) These are precisely the kinds of problems that slip through when many people edit a product over years. The model is simple, but the same approach scales: automated testing frameworks can crawl real interfaces to build the graph, and model checkers can verify properties such as 'from every state, a cancel action leads back to Home within two steps'.

Worked examples