Question 3 of 4: Human-Computer Interface Evaluation of a GPS Navigation Unit

Question 3: Human-Computer Interface Evaluation of a GPS Navigation Unit (20 marks: a–12, b–8)

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.

(a) Human Factors Evaluation Methods

Two complementary methods are used because they surface different classes of issue: an expert-based inspection method finds structural/design-principle violations quickly and cheaply without needing real drivers, while a user-based method captures issues (misinterpretation, task-completion failure, physical/attentional workload) that only emerge from actual use, including issues an expert inspection can miss.

1. Heuristic evaluation (expert inspection method). A small panel (3–5) of human-factors/usability experts independently reviews the interface against a recognized heuristic set (e.g. Nielsen's usability heuristics: visibility of system status, match between system and real world, consistency and standards, error prevention, recognition over recall, minimalist design) and against automotive-specific in-vehicle-display guidance, flagging every violation with a severity rating. Data generated: a prioritized list of specific design violations (e.g. "icon row lacks labels – violates recognition-over-recall"), each tagged with a severity/frequency estimate – qualitative, expert-judgment data, fast and inexpensive to collect, but not validated against real driver behaviour.
2. Usability/task-performance testing with representative users (empirical method). Representative drivers (ideally including a range of ages/experience with in-vehicle systems, tested in a simulator or a controlled stationary vehicle for safety) are given realistic navigation tasks (e.g. "cancel the current route and start a new one", "identify your next turn without looking away from the road for more than 1.5 s") while task completion, error rate, and (in a driving simulator) glance duration/frequency away from the road are recorded, often paired with a post-task think-aloud or interview. Data generated: quantitative performance data (task success rate, time-on-task, number/duration of glances, error counts) plus qualitative verbal-protocol data explaining why an error occurred – directly measures whether the interface achieves its real safety-critical goal (minimal visual/attentional demand while driving), which a heuristic review alone cannot confirm.

Used together, the heuristic evaluation cheaply generates the candidate issue list evaluated in part (b) below, and usability testing would then confirm which of those issues actually degrade real task performance and by how much, and would surface any additional issue the expert panel missed.

(b) Human-Computer Interaction Issues Identified

[Figure not reproduced: Fig. 2 — the interface redrawn with the five interaction issues identified below numbered against their on-screen location. See the official exam paper.]

1. Ambiguous, low-visibility menu control. The "MENU" chevron is small, low-contrast, and unlabeled beyond the single word – it fails visibility of system status/affordance: a driver cannot tell at a glance whether it opens a full menu, a settings panel, or the current-route options, and its small touch target is difficult to hit accurately without diverting visual attention, which is precisely the scarce resource this interface must conserve.
2. An irreversible, high-consequence action given equal visual prominence to routine controls. "CANCEL NAVIGATION" is sized and positioned like any other button, yet it is destructive and not easily undone mid-drive – this violates the error-prevention heuristic (a high-cost action should require confirmation or be visually/physically separated from routine controls) and risks an accidental cancel from a stray touch while driving over road vibration.
3. No visual hierarchy between the primary turn instruction and secondary route information. "King Edward Street, 500 m" (the single most safety-critical piece of information – the very next action the driver must take) is rendered at the same size/weight as the destination ETA and the two alternate-route options beside it; a glance long enough to correctly parse which of the four numbers is the immediate turn is longer than the interface's context (a driver, glancing briefly) allows.
4. Competing route-choice panel adjacent to the active-turn panel. "Rideau Street 1.2 km" / "Dalhousie Street 2.0 km" appear directly beside the actual next-turn instruction with near-identical formatting, inviting the driver to misread an alternate route option as the current instruction – a match-between-system-and-real-world and layout-grouping failure (dissimilar-function items should not be visually grouped as if related).
5. Unlabeled icon row demanding recognition-only interpretation. Seven small, closely spaced icons along the bottom edge carry no text label and are visually similar in size/colour, forcing the driver to rely on memorized icon meaning (violates recognition over recall) and presenting small touch targets (Fitts's-law penalty) exactly where inadvertent activation while driving is most likely.

Common thread across all five: this is a safety-critical, divided-attention interface (used while driving), so every issue above is more consequential here than the identical flaw would be on a desk-bound screen – the redesign priority should be whichever issue most increases glance duration/frequency away from the road, which usability testing (part a) would rank empirically.