Mental models and interface design
How affordance, constraints and conventions each lean on a user's existing mental model to steer them toward the secure choice, and the lecture's closing take-away messages on designing for real users rather than blaming them.
- Define a mental model and explain why security designers can lean on the ones users already carry.
- Distinguish affordance, constraints and conventions, and give a security-interface example of each.
- Explain how each of the three concepts uses or shapes a user's mental model.
- State the lecture's take-away messages on human-centred security design, and explain why blaming the user is the wrong response to a failed security feature.
12 min read
Intuition
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 picture of how a system behaves, built from past experience rather than from the system’s actual design. 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.
Mechanism
The lecture defines a mental model as the 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. Companies such as Apple and Google are, in the lecture’s own 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.
Three concepts describe how that steering happens.
| 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 |
Exam detail
The lecture ties each concept back to the mental model it works through: 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, and why users recognise it on sight without being told what it
means.
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.
Exam detail
Take-away messages. The lecture closes the module with four points about how to respond when a security feature does not work as intended.
Design focus over user blame. If a security feature fails in practice, the lecture’s position is that 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 assumption 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; here
it stands as a named take-away in its own right.
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 already 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.
Aside
The lecture illustrates affordance, constraints and conventions 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 from the source material. Each example in the table above is still the lecture’s own, taken from the prose description of the figure rather than the image itself: 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.
Source
Week 2 Notes PDF