19-Soft-B2 User Interface · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2014 — 04-Soft-B2, User Interface (closed book, 3 hours). Part A: answer any FIVE of the NINE questions (10 marks each); Part B: answer ALL FIVE questions (10 marks each), all based on the same case study — Medic123's ambulatory smart infusion pump and its Windows drug-library upload software, designed by MedicSoft using a User-Centered Design (UCD) approach for hospital pharmacists. Most questions call for essay-format answers; clarity and organisation count. This solution answers all fourteen questions as a full study resource.
Reference texts. Rogers, Sharp & Preece, Interaction Design: Beyond Human-Computer Interaction, 5th ed., Ch. 1–3 (interaction design, cognitive aspects, mental models), Ch. 9–10 (prototyping, personas), Ch. 11–12 (data gathering, requirements), Ch. 15–16 (evaluation, lab vs. field studies); Nielsen, Usability Engineering, Ch. 4–6 (usability heuristics, iterative design, usability testing); Shneiderman, Designing the User Interface, 6th ed., Ch. 2 (guidelines, principles), Ch. 12 (internationalization); Norman, The Design of Everyday Things, Ch. 1–4 (visibility, affordances, feedback, conceptual models).
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.
Visibility is the design principle that the functions and state of a system relevant to the user's current task should be perceivable, not hidden — the more visible a function or a piece of state is, the more likely a user is to know it exists and know what state the system is in. In UI design this means surfacing controls and status (the current infusion rate, whether a drug-library edit has been saved and/or uploaded) directly on screen rather than burying them in menus or requiring the user to remember them; low visibility (a critical setting several menu levels deep) is a common source of the "I didn't know it could do that" and "I didn't realise it hadn't uploaded yet" classes of error.
Affordances are the perceived properties of an object or control that suggest how it can be used — a button that looks raised and clickable "affords" pressing; a slider track affords dragging. In UI design, controls should be given a visual appearance (shape, shading, position) that correctly signals their actual behaviour, so users can figure out how to operate a new interface element without being told — e.g. a toggle that visually resembles a physical switch affords flipping, while a flat, unstyled label that is secretly clickable provides no such cue and will simply be missed by most users.
Feedback is the principle that the system should promptly and clearly communicate the result of a user's action back to the user, so they know what happened and can decide what to do next. In UI design this means every user action — clicking "save," dragging a drug into a library, initiating an upload to a pump — should produce an immediate, unambiguous response (a confirmation message, a progress indicator, a state change in the display); the absence of feedback (a "save" button that gives no visible response) leaves the user unsure whether the action succeeded, and in a safety-relevant context like a drug library, an unconfirmed upload can mean a pump is left running an outdated formulary without anyone realising it.
The three principles reinforce one another as a chain across the interaction: visibility lets the user see what is possible and what state the system is in before acting; affordances tell the user how to act on what they see; and feedback confirms to the user what actually happened after they acted — a break at any point in that chain (something invisible, something with a misleading affordance, or an action with no feedback) is a direct, well-documented source of user error.
