Question 3 of 14: Designer Knowledge — User Characteristics and Other Knowledge Areas

Question 3: Designer Knowledge — User Characteristics and Other Knowledge Areas (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 — four user characteristics. (1) Domain/task expertise — how much the user already knows about the task domain (here, pharmacy practice and infusion therapy); relevant because it determines how much explanatory scaffolding the interface must provide versus how much it can assume, and how much terminology can be used without definition. (2) Computer/technology proficiency — the user's general familiarity with software and with Windows-style interaction conventions; relevant because it sets the baseline interaction vocabulary (menus, drag-and-drop, keyboard shortcuts) the designer can safely rely on without additional training. (3) Physical and perceptual characteristics (age-related vision/motor changes, colour-vision deficiency, etc.); relevant because they constrain concrete design choices such as minimum font size, control target size, and whether colour alone is used to distinguish states (e.g. a dosage warning must not rely on red/green alone). (4) Working context and task frequency — whether the task is performed rarely (a pharmacist uploading a library once or twice a year) versus frequently, and under what time pressure/interruption profile; relevant because infrequent users need interfaces that are easy to re-learn (clear labels, visible affordances, minimal reliance on memorised shortcuts), whereas frequent users benefit from efficiency features (shortcuts, batch operations) that would only slow an infrequent user down.

Part B — two more knowledge areas. (1) Knowledge of the task and its domain — understanding what the user is actually trying to accomplish (build a unit-specific drug library, set safe dosing limits) and the real-world workflow surrounding it (how a hospital pharmacy validates and distributes a formulary change), independent of any particular user; relevant because an interface can be perfectly usable in isolation and still fail if its task model does not match how the work is actually organised and sequenced in practice. (2) Knowledge of general UI/HCI design principles and guidelines (e.g. Shneiderman's golden rules, Nielsen's heuristics, platform conventions for the target OS) — relevant because it supplies design solutions that generalise across systems and users, so the designer is not reinventing consistency, feedback and error-prevention conventions from first principles for every project, and so the resulting interface matches user expectations built from other Windows applications.