Question 2 of 14: Mental Models and Interface Metaphors

Question 2: Mental Models and Interface Metaphors (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part A — mental models. A mental model is the internal, simplified representation a person builds and carries in their head of how a system works — what it does, why it behaves as it does, and what will happen if they take a given action — built up from experience, instruction and analogy with other systems rather than from the system's actual internal logic. Mental models matter to UI design because users act on their mental model of the system, not on how the system actually works internally: if the interface's behaviour matches what the user's mental model predicts, the system feels predictable and learnable; if it diverges, the user makes errors and forms an inaccurate model that leads to further errors (e.g. a pharmacist who believes "saving" a drug-library edit uploads it to the pumps immediately, when in fact a separate explicit "publish" step is required, will fail to distribute a critical dosage-limit correction).

Part B — interface metaphor. An interface metaphor is a design device that presents a new, unfamiliar system in terms of a familiar real-world (or already-familiar digital) concept, so users can transfer their existing knowledge of that concept to predict how the new interface will behave. Example: the drug-library editor could use a "library/shelf" metaphor — drugs organised into named "shelves" corresponding to hospital units (maternity, ICU), with drag-and-drop "checking a drug out" of a master list onto a unit's shelf to add it to that unit's library — letting pharmacists reuse their familiarity with organising a physical reference library.

Part C — relationship, pros and cons. A well-chosen interface metaphor is one concrete way of shaping the user's mental model: it deliberately primes the user to import an existing, familiar mental model (of the metaphor's real-world source) as a starting point for the mental model they build of the new system. Pros: reduces learning time by leveraging prior knowledge; makes the system's behaviour more predictable when the metaphor genuinely matches the underlying functionality; gives designers and users a shared vocabulary ("shelf," "checked out"). Cons: a metaphor that only partially matches the real behaviour actively misleads users once they push past the surface analogy (e.g. a "shelf" suggests physical exclusivity — that a drug "checked out" to one unit's shelf is unavailable elsewhere — which may not reflect how the underlying shared database actually behaves); metaphors can also constrain a design to the limitations of the source domain (a desktop "folder" metaphor struggles to represent capabilities, like full-text search across all libraries, that have no physical-filing analogue) and can fail across cultures where the source concept is unfamiliar.