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.
Low-fidelity stage. I would build a horizontal, paper prototype (index cards or printed screen sketches for each main screen — library list, drug editor, unit assignment, upload/confirmation screen — with sticky-note overlays representing dynamic elements like dropdown menus and confirmation dialogs) using sketching and paper prototyping techniques, deliberately kept rough so reviewers critique structure and workflow rather than visuals. This stage would involve the UI designer (myself), the product manager, and, critically, a small panel of representative pharmacists (per the persona work of Question 6) in participatory walk-through sessions, where a facilitator "runs" the paper screens by hand in response to what the participant points at, simulating the interaction (essentially a low-tech Wizard of Oz). This stage is used to validate the overall screen flow, information architecture and terminology before any code is written, at minimal cost of change.
Transforming to high-fidelity. Once the paper walk-throughs converge on a stable structure, I would move to a digital wireframing/mock-up tool to produce clickable, static-then-interactive screens with real layout, typography and colour, still without live backend logic (a mid-fidelity step) — involving the UI designer and a visual/UX designer, reviewed again with the same pharmacist panel. Finally I would build a vertical, high-fidelity interactive prototype covering the highest-risk task end to end (building and uploading a real drug library, including validation and confirmation feedback), implemented with real interaction logic (even if the backend upload to an actual pump is stubbed/simulated) — involving the UI designer, a front-end developer, and again pharmacist participants for formative usability testing (Question 4/5) before a final field evaluation (Question 7) validates the design under real hospital conditions.