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.
User interface design guidelines (platform style guides such as Apple's Human Interface Guidelines or Google's Material Design, together with general HCI guideline sets such as Shneiderman's eight golden rules or Nielsen's heuristics) play several distinct roles when building a medium-fidelity mobile prototype. Why use them: (1) they encode accumulated design knowledge and empirical usability findings that a single designer or one round of user testing could not reproduce from scratch, so relying on them avoids re-discovering well-known usability pitfalls the hard way; (2) they ensure consistency with the platform users already know — a mobile user brings expectations from every other app on their phone (swipe-back gesture, standard navigation-bar placement, standard icon meanings), and violating those expectations imposes an unnecessary learning cost and increases error; (3) they give the design team and stakeholders a shared, objective vocabulary for critiquing the prototype ("this violates the guideline on touch-target size") rather than relying purely on individual taste; and (4) following platform guidelines is often a practical requirement for app-store acceptance and cross-app interoperability on the target platform.
How to use them: guidelines are applied as a checklist and a source of concrete constraints during design — e.g. minimum touch-target size (~44×44 pt on iOS), standard navigation patterns (tab bar vs. hierarchical drill-down), colour-contrast minimums for accessibility, and standard iconography — rather than as rigid rules that override user research when the two genuinely conflict. At medium fidelity specifically, guidelines are used to make the prototype's interaction patterns (not just its visuals) behave the way a real mobile user already expects, so usability testing on the prototype measures the app's actual concept and workflow rather than being confounded by users struggling with unfamiliar, non-standard gestures or layouts that have nothing to do with the design question being tested. Guidelines are a starting point and a safety net, not a substitute for testing the specific design with real users — a guideline-compliant interface can still fail for this particular task and this particular user population, which is exactly what the prototype-and-evaluate cycle is for.
