Human-Centred IoT Design · Study deck
UX Evaluation: Evidence for Decisions
Is this setup flow ready for a field pilot?
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The test should include the physical device, mobile app, QR or setup code, Bluetooth discovery, Wi-Fi provisioning, Matter commissioning or vendor-cloud account binding, permission prompts, and a support path.
- Explain: Task observation reveals behaviour in the tested scenario; logs can show when the device last reported; an accessibility review checks whether the state is perceivable through other modes.
- Explain: Stopping at the first failed branch gives the team a sharper diagnosis and a testable correction, while later branches remain open until the earlier barrier is removed.
- Choose a defensible design using tie evaluation to decisions.
Major section
Heuristic Review
A completed action still needs a success check because the system may accept input without producing the intended result.
- Heuristic review is not proof that real users will succeed.
- If so, ask whether its wording, state, and consequence are understandable.
- Stopping at the first failed branch gives the team a sharper diagnosis and a testable correction, while later branches remain open until the earlier barrier is removed.
Major section
Issue Record Workflow
Keeping these fields together matters for IoT failures because the same visible symptom may come from permission, stale data, a delayed command, or a device fault.
- Severity explains the consequence rather than merely counting how often a screen looked wrong.
- The proposed fix then needs an acceptance condition that a reviewer can observe.
- Retest repeats the relevant route after the change.
Major section
Incremental Examples
A beginner evaluation can inspect a thermostat or room-sensor card before user testing.
- The evaluator checks whether current, stale, offline, updating, and low-battery states have different labels, whether color is not the only signal, whether the latest timestamp is visible, and whether the next action is clear.
- The test should include the physical device, mobile app, QR or setup code, Bluetooth discovery, Wi-Fi provisioning, Matter commissioning or vendor-cloud account binding, permission prompts, and a support path.
- The issue record should separate user hesitation from technical state: BLE timeout, wrong network, Thread border-router absence, expired invite, account-role mismatch, or cloud service delay.
Major section
Common Defects
Opinion testing: asking "what do you think?" instead of observing task completion.
- Heuristic overconfidence: treating expert review as proof that real users will succeed.
- Accessibility late review: checking accessibility after layout, controls, and device placement are already accepted.
- No support-path test: ignoring whether support can diagnose and explain failures.
Major section
How Different Methods Constrain a Claim
A visibility-of-status heuristic can flag an ambiguous label, but it cannot show how often people make the wrong decision.
- Task observation reveals behaviour in the tested scenario; logs can show when the device last reported; an accessibility review checks whether the state is perceivable through other modes.
- The chapter’s evidence decision record should keep each method’s limits beside the proposed fix.
- Joining these sources at the same event and timestamp prevents a design-only explanation for a network fault.
Deck summary
Key takeaways
A completed action still needs a success check because the system may accept input without producing the intended result.
- Keeping these fields together matters for IoT failures because the same visible symptom may come from permission, stale data, a delayed command, or a device fault.
- A beginner evaluation can inspect a thermostat or room-sensor card before user testing.
- Opinion testing: asking "what do you think?" instead of observing task completion.
- A visibility-of-status heuristic can flag an ambiguous label, but it cannot show how often people make the wrong decision.
Retrieval practice
Recall check 1 of 2
UX Uma says: answer from memory, then check your reasoning.
Q1A team asks five employees to explore a smart-home app and say what they think. Everyone says it looks clean. After launch, customers cannot complete setup when Wi-Fi pairing fails. What was the main evaluation problem?
Show answer
Answer: D Evaluation should be task-based, representative, and include realistic connected-system failure states.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A heuristic review flags an unclear offline label. What evidence tests the consequence?
Show answer
Answer: A The task links the wording to a decision and actual state.
Q3Support tickets report delayed sensor alerts. What should a release decision connect?
Show answer
Answer: B The sources distinguish presentation from delivery delay.
Print reference
Answers
Answer key.
- D · Evaluation should be task-based, representative, and include realistic connected-system failure states.
- A · The task links the wording to a decision and actual state.
- B · The sources distinguish presentation from delivery delay.