Supervision Worked Answers
Supervision 1, Question 1: Requirements for Taxi App and Air Traffic Control
These are model answers — in a Tripos, you would phrase each requirement as a testable statement with a one-line rationale.
(a) Cambridge Taxi Booking App
Functional: request a ride, view driver location in real time, pay in-app, rate driver, schedule advance bookings.
Data: pickup/drop-off GPS coordinates, payment card token, trip history, driver ETA and location data.
Environmental: used outdoors, often one-handed while carrying bags; variable network coverage in rural areas around Cambridge; used in daylight and darkness (screen must adapt); may be used in social groups (shared booking).
User Characteristics: wide age range including tourists unfamiliar with the city; occasional users (low frequency → favour Recognition over Recall); some users with visual or motor impairments; variable technical literacy.
Usability Goals: Efficiency (fast booking under time pressure — the user is outside, possibly in rain); Safety (accurate location, no incorrect fare charged); Learnability (first-time tourist use without training).
UX Goals: feeling of trust and control; low anxiety while waiting for pickup; satisfying to see the driver approaching on the map.
(b) Air Traffic Control Scheduling System
Functional: display real-time aircraft positions on a map; propose take-off/landing sequencing; allow manual override of proposed sequence; log all decisions for audit; alert on potential conflicts.
Data: radar/transponder feeds; runway status; weather data (wind speed/direction, visibility); flight plans — all with extremely high accuracy and low latency.
Environmental: high-stress, low-light control-room environment; shared display among multiple controllers (collaborative work); 24/7 operation; must remain usable under emergency conditions.
User Characteristics: highly trained expert users who have completed years of training and certification; frequent, expert use → favour Recall-based shortcuts, dense information display, and efficiency over learnability.
Usability Goals: Safety is paramount (errors can be fatal — this is the primary usability goal); Effectiveness; Efficiency under time pressure.
UX Goals: secondary to safety and efficiency — the system’s emotional qualities are less important than its correctness. However, a controller who trusts the system is a safer operator than one who distrusts it and overrides unnecessarily.
Supervision 1, Question 2: Suitable vs Unsuitable Projects
See the full discussion in the User Research Methods notes for detailed justifications. The six methods and a suitable/unsuitable pair for each:
| Method | Suitable for | Unsuitable for |
|---|---|---|
| Questionnaires | Large-scale course-feedback system redesign (summative, quantifiable) | Early exploratory mental-health app (don’t yet know what to ask) |
| Interviews | Understanding why seniors distrust a banking app (rich, probing, formative) | A/B testing button colour (too slow, small-sample) |
| Ethnography | Redesigning hospital ward communication (socio-technical, contextual) | Optimising KLM timing of a shortcut (quantitative, controlled) |
| Lab-based observation | Comparing checkout-flow completion time (controlled, statistical) | Understanding smart-home use in family life (low ecological validity) |
| Focus groups | Gauging teacher reactions to a classroom app (range of views) | Sensitive personal topics like financial hardship (social pressure) |
| Card sorting | Designing e-commerce navigation (IA discovery) | Evaluating an ATM’s fixed sequence (not browsable hierarchy) |
Supervision 1, Question 3: Participatory Design
(a) Would design methods need to change? Yes — and substantially. When users are on the design team, many analytical methods (HE, CW) can be conducted continuously rather than as discrete evaluation events, because the user’s perspective is always present. Prototyping becomes collaborative — users participate in sketching sessions rather than just reacting to designer-produced prototypes.
(b) Benefits:
- Users bring domain knowledge and tacit understanding that designers cannot acquire through short research engagements.
- Design decisions are reality-checked continuously, reducing the risk of building the wrong thing.
- User buy-in is built in from the start — no “selling” the design to users later.
(c) Challenges:
- Users may lack the vocabulary to articulate design reasoning — they know what feels wrong but not why. The designer must translate user feedback into design principles.
- A single user is not representative of all users — participatory design with one or two users risks biasing the design toward their preferences.
- Power dynamics: users may defer to designers’ perceived expertise rather than asserting their own knowledge. The facilitator must actively create space for user input.
- Users may struggle to think beyond the current system — “this is how we’ve always done it.”
Mitigations: involve multiple, diverse users (not just one); use methods that do not require design vocabulary (sketching, storyboarding, card sorting); the designer’s role shifts from “author” to “facilitator and synthesiser.”
Supervision 2, Question 1(a): HE of ikea.com
A heuristic evaluation of the IKEA website using Nielsen’s 10 heuristics would identify issues such as:
- #4 Consistency and Standards: product pages on different regional sites (ikea.com/gb vs ikea.com/de) use different layouts and terminology for the same products — inconsistent across the brand.
- #6 Recognition Rather Than Recall: the product code (e.g. “AA-1234-567”) required for in-store collection must be remembered from the product page and re-entered at collection — no way to save or copy it conveniently on mobile.
- #3 User Control and Freedom: the checkout process has no “back” or “edit cart” button that is clearly visible — users feel trapped once they begin.
- #8 Aesthetic and Minimalist Design: product pages contain dense specifications, care instructions, sustainability ratings, and dimensions all in one scrolling block — information overload.
- Severity ratings would be assigned (0–4) for each violation, and findings aggregated across 3–5 independent evaluators.
Supervision 2, Question 1(b): CW of ikea.com Purchase Flow
Inputs: target user = a first-time IKEA online shopper; task = purchase a desk lamp.
Action sequence and walkthrough:
-
Navigate to ikea.com/gb/en/ → Q1 OK (user knows they need to find lamps). Q2 Possible fail — the lamp category is buried under “Products” → “Lighting” → “Desk lamps” — three levels deep. Q3 Fail if the user expects “Lamps” as a top-level category and does not think to look under “Lighting.”
-
Select a specific lamp → Q2 Possible fail — filters are not immediately visible on mobile; the user must scroll past promotional banners first. Q3 OK once the lamp is visible and tappable.
-
Add to cart → Q3 Possible fail — the “Add to Bag” button label differs from the user’s mental model (“Add to Cart”). Q4 OK — a confirmation animation confirms success.
-
Proceed to checkout → Q1 OK. Q2 Possible fail — the checkout button is small and positioned in the top-right corner on mobile, away from the thumb zone. Q3 OK once found.
Redesign suggestions: flatten the “Products → Lighting → Desk lamps” hierarchy to surface “Lamps” as a top-level category; rename “Add to Bag” to “Add to Cart” for consistency with user expectations; reposition the checkout button to the bottom of the screen on mobile.
Comparison of HE and CW findings: HE surfaces broad consistency and navigation issues across the entire site. CW surfaces task-specific learnability failures — the CW found the buried lamp category that HE might miss because HE evaluates the whole interface and an evaluator might not walk through that specific task. The methods are complementary: HE for breadth, CW for depth on specific, high-priority tasks.
Supervision 2, Question 2: Usability Testing Research Plan
For a new “product photos in real homes” feature on ikea.com:
Objectives: determine whether the new feature increases purchase confidence (measured by self-report) and whether users understand that the photos show other customers’ homes (not staged showrooms).
Stakeholders: primary — online shoppers considering a furniture purchase; secondary — IKEA marketing team who supplied the photos; tertiary — customers who submitted photos of their homes (privacy concern: are they identifiable?).
Method: moderated usability testing with 8–12 participants (representative of IKEA’s target demographic), conducted remotely via screen-sharing. Think-aloud protocol — participants verbalise their thoughts while browsing product pages.
Data collected: task-completion time for “find reviews and real-home photos”; post-task Likert-scale ratings for purchase confidence and trust; qualitative observations from think-aloud transcripts.
Analysis: compare purchase-confidence ratings for products with vs without real-home photos (within-subjects, sign test for non-parametric comparison). Thematically code think-aloud transcripts for confusion, delight, or privacy concerns.