Mental models and interface design

Users act on a mental model, so design the interface to steer it

A user does not read the manual before clicking a button. They act on whatever they already expect a button, a warning, or a settings panel to do, based on every similar screen they have used before. That expectation is a mental model: an internal representation a person builds to understand and interact with a system, drawn from their own experience, beliefs and interpretations rather than from the system’s actual internals. Get the model right and the secure choice feels obvious. Get it wrong and the user does something that looks careless but was, from inside their own model, entirely reasonable.

Companies such as Apple and Google are, in the lecture’s phrasing, very good at exploiting these models. A security designer has the same option: rather than fighting the model a user already carries, design the interface so the model steers them toward the secure choice on its own.

Affordance, constraints and conventions are the three steering tools

Concept	What it does	Security example
Affordance	Guides the user toward the correct action	A “Sign in” button stays grey while the form is incomplete, then turns green once every required field is filled: the colour change itself signals that pressing it will now do something
Constraints	Limits which interactions are possible at all	Password length requirements and restrictions on which characters are accepted, so the field will not take an 11th character past a 10-character maximum, or a symbol outside the allowed set
Conventions	Matches a pattern the user already knows from elsewhere	A pause symbol (two vertical bars) means the same thing on every remote control, because every remote has used the same symbol for decades

Each concept works through the mental model. Affordance leans on the model to indicate which actions are possible right now. Constraints shape the model by removing the wrong options before the user can try them. Conventions align directly with a model the user already carries from an entirely different system. 02-02 covers a related convention, the padlock icon next to a browser’s address bar, and what goes wrong when a user trusts it uncritically. That page is about the bias exploited once the convention is trusted; this page is only about the convention itself.

Pitfall

The lecture’s own practice quiz tests this mix-up directly: “affordance is the idea of designing systems where users are constrained from making errors” is marked wrong, because that sentence describes constraints, not affordance. Affordance is about signalling what a user can do; constraints are about physically preventing what they cannot. Losing marks here almost always means naming the right concept while describing the wrong one.

Recall

A 'Sign in' button is grey and unclickable until every required field is filled, then turns green. Which of the three concepts is this, and how does it use the user's existing mental model?

Affordance. The colour and clickability change together signal “not yet available” and then “available now,” matching the widely shared mental model that a greyed-out interface element is inactive and a coloured, enabled one is not.

Optional aside

The lecture illustrates the three concepts with a figure showing a UI panel for each: a button, a movement-limited panel, and a set of recognisable symbols. That figure did not survive extraction. Each example in the table above is still the lecture’s own, taken from the prose description of the figure: the notes describe the button turning green and the password-field restrictions directly, and the slides name the DVR pause symbol as their example of a convention.

When a security feature fails, fix the design, not the user

The lecture closes the module with four take-aways.

Design focus over user blame. If a security feature fails in practice, blaming the user is unproductive: the fix belongs in the design, not in a lecture to the person who worked around it. Relying on user education instead of better design is named explicitly as insufficient on its own.

The developer-versus-user experience gap. Developers assume users share their own technical expertise and their own tolerance for stress under a security decision. Neither holds: most users have less technical background, and less patience for friction in the moment, than the person who built the system. 02-01’s programmer-versus-secretary example is the psychological-acceptability side of this same gap.

Psychological factors as a design input. The biases, memory limits and defaults covered earlier in this module are not background detail. The lecture treats them as inputs a design process accounts for from the start, not patches applied once a feature has shipped.

Stakeholder integration. A design process that brings in stakeholders’ perspectives, not only the development team’s own, produces security solutions that are more usable and harder to defeat.