19-Soft-B2 User Interface · May 2015
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2015 — 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 — Happy Medical Clinic, a Toronto medical clinic switching from paper-based practice to an electronic health record (EHR) system purchased from VisualEHR Inc., an off-the-shelf vendor willing to customize the product to the clinic's needs. 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.
Part A — the model. A widely used iterative UCD process model has four core activities performed in a repeating cycle: (1) Establish requirements — understand users, their tasks and the context of use (e.g. interview Happy Medical Clinic's front-desk staff, nurses and physicians about how they currently book, chart and bill); (2) Design alternatives — generate candidate design solutions (sketches, screen flows) that meet those requirements; (3) Build prototypes — construct interactive, communicable versions of the design ideas, at a fidelity appropriate to the current question; (4) Evaluate — test the prototype with real or representative users and feed the findings back into the requirements/design activities. The four activities form a closed loop — evaluate → requirements/design — that is walked through repeatedly rather than once.
Part B — why it is iterative. The model is iterative because no single pass through requirements-design-build-evaluate is expected to produce a final, correct interface: user needs are rarely fully known up front, design ideas that look sound on paper often fail in evaluation, and evaluation findings routinely reveal requirements that were missed or misunderstood in the first pass. Each cycle produces a prototype that is deliberately treated as provisional, tested, and revised — the outputs of evaluation feed directly back as inputs to the next requirements/design pass, so understanding of the problem and the quality of the solution both improve incrementally across cycles rather than being "got right" once. For Happy Medical Clinic, an early cycle might reveal that receptionists need a different EHR screen than nurses reviewing charts — a distinction the first requirements pass may not have captured — and later cycles refine that split.
Part C — where evaluation happens. User evaluation/usability testing is carried out in the Evaluate activity, which occurs at the end of every cycle, but at low, informal fidelity as early as the very first prototype (a paper sketch reviewed with a receptionist takes only minutes and catches gross conceptual errors before any code is written) and again, more formally, after every subsequent higher-fidelity prototype through to a final validation/summative test on a near-final build. In other words, evaluation is not a single late-stage gate; it belongs at every iteration of the cycle, applied at a level of rigour appropriate to the prototype's current fidelity.
