Human-Centred IoT Design · Study deck
Context Analysis: Physical Environments
Check the setting for bright sunlight, darkness, glare, vibration, or motion.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The chapter’s field-validation approach tests whether a requirement derived from those observations holds outside the lab, while privacy review limits any contextual data retained for later analysis.
- Explain: A voice-first device may be inappropriate in a shared office, care setting, or multilingual household if commands expose private information or fail for common accents and vocabulary.
- Explain: The design should collect the least sensitive context that can support the task, explain the reason at the point of use, and preserve useful fallback behavior when possible.
- Test physical context with a concrete scenario and pass criteria.
Major section
Cultural and Organization Context
Culture is not only country or language.
- It includes household norms, workplace rules, role expectations, privacy expectations, regulatory environment, training practice, and trust in automation.
- A voice-first device may be inappropriate in a shared office, care setting, or multilingual household if commands expose private information or fail for common accents and vocabulary.
- Design implications may include multilingual content, icon support, local units, quiet interaction modes, consent screens, manual controls, clearer automation explanations, or training material.
Major section
Accessibility Context
Accessibility should be reviewed as context, not as a final compliance layer.
- For connected devices, accessibility also includes the physical device, local indicator, printed label, mounting position, setup flow, support path, and maintenance routine.
- Design implications should be recorded as acceptance criteria.
- For example, "critical state must not rely on color alone" is stronger than "consider accessibility.".
Major section
Context Analysis Record
Observed context can include physical, social, time, technical, cultural, and access conditions.
- Evidence and boundary fields keep a single site observation from standing for all users.
- The final decision, owner, and recheck point make a changed installation or role a reason to review the choice again.
- Design implication: what must change or be protected.
Major section
Context Analysis Record (continued)
Boundary: what the evidence does not prove.
- Owner and change condition: who owns the next action and when the review must run again.
- The record should be short enough to maintain.
- A long report that nobody updates is less useful than a concise record tied to a real decision.
Major section
Context-Aware Automation
Context-aware IoT systems can be helpful, but context signals are evidence, not certainty.
- "If the phone is near home, turn on the lights.".
- For higher-risk actions, confirmation or suggestion may be better than automatic action.
- For low-risk routine actions, automation may be acceptable if override and feedback are clear.
Major section
Privacy and Minimum Context
Context-aware systems can easily collect more data than the task requires.
- Context analysis should therefore include a minimum-context check.
- A room-comfort system may need occupancy state, but it may not need identifiable movement history for every person in the household.
- The design should collect the least sensitive context that can support the task, explain the reason at the point of use, and preserve useful fallback behavior when possible.
Major section
Kitchen Measurement Review
Surface: local device controls and companion recipe screen.
- The user may step away to stir, wash, or answer another question.
- The screen may be viewed from an angle or partly blocked by bowls.
- Primary tare and confirm actions need tactile controls or another input that works with messy hands.
- The device should preserve task state across ordinary interruptions.
Major section
Kitchen Measurement Review (continued)
Critical state needs visual feedback that is readable at kitchen distance.
- Cleaning and water exposure must be part of the prototype test.
- A bench prototype can test input and feedback.
- A field test in real cooking conditions is needed before claiming the interaction works in context.
Major section
Worked Review: Shared Care Reminder
Surface: wearable reminder, caregiver app, and support handoff.
- Task: understand a reminder, acknowledge it, and know when help is needed.
- Context: shared responsibility, variable hearing/vision/dexterity, privacy needs, intermittent phone access, and changing routines.
- The person receiving the reminder may not have the phone nearby.
- Caregivers need status without seeing more personal detail than necessary.
Major section
Worked Review: Shared Care Reminder (continued)
Audio-only alerts may fail or disturb others.
- Missed acknowledgements need escalation rules that avoid false alarms.
- Reminder state should be available on the local wearable and caregiver view.
- Acknowledgement should work with limited dexterity and not require a complex app path.
- Caregiver status should distinguish acknowledged, missed, snoozed, device offline, and stale data.
Major section
Why Context Changes the Observed Outcome
Moisture can alter touch input; glare and viewing angle can make a correct measurement unreadable; a shared counter can interrupt the task before acknowledgement.
- Those conditions affect the interaction even when sensing and computation are correct.
- A context record therefore needs the environment, task step, device state, participant role, and observed consequence.
- The chapter’s field-validation approach tests whether a requirement derived from those observations holds outside the lab, while privacy review limits any contextual data retained for later analysis.
Major section
Summary
Good context analysis prevents lab-only designs, overconfident automation, privacy creep, inaccessible physical interactions, and unsupported claims about how a device will work in the field.
- Context-of-use analysis helps IoT teams design for the real conditions where connected systems are used.
- The goal is not to collect anecdotes.
- The goal is to translate observed conditions into design requirements, evidence boundaries, and change conditions.
Deck summary
Key takeaways
Culture is not only country or language.
- Accessibility should be reviewed as context, not as a final compliance layer.
- Observed context can include physical, social, time, technical, cultural, and access conditions.
- Boundary: what the evidence does not prove.
- Context-aware IoT systems can be helpful, but context signals are evidence, not certainty.
Retrieval practice
Recall check 1 of 3
UX Uma says: answer from memory, then check your reasoning.
Q1A smart appliance prototype works in the lab, but the field team observes that users often operate it with wet hands, while distracted, and from a side angle. What is the strongest context-analysis response?
Show answer
Answer: C Context-of-use analysis connects observed conditions to design requirements, evidence boundaries, and change conditions.
Retrieval practice
Recall check 2 of 3
UX Uma says: answer from memory, then check your reasoning.
Q2A kitchen measurement display passes a bench test but cannot be read under counter lighting. What changes?
Show answer
Answer: C The field condition concerns visibility during the task.
Retrieval practice
Recall check 3 of 3
UX Uma says: answer from memory, then check your reasoning.
Q3A shared care reminder sounds during a noisy routine. Which context record is useful?
Show answer
Answer: A These fields link the environment to an observed outcome.
Print reference
Answers
Answer key.
- C · Context-of-use analysis connects observed conditions to design requirements, evidence boundaries, and change conditions.
- C · The field condition concerns visibility during the task.
- A · These fields link the environment to an observed outcome.