UX Design · Study deck
Context Analysis: Physical Environments
bright sunlight, darkness, glare, vibration, or motion. noise, echo, water, dust, dirt, grease, cold, heat, or humidity.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- 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.
- Explain: 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.
- Explain: Accessibility should be reviewed as context, not as a final compliance layer.
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
Design implication: what must change or be protected.
- 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
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.
- Design implication: what must change or be protected.
- Context-aware IoT systems can be helpful, but context signals are evidence, not certainty.
- Context-aware systems can easily collect more data than the task requires.
Retrieval practice
Recall check
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: A Context-of-use analysis connects observed conditions to design requirements, evidence boundaries, and change conditions.
Print reference
Answers
Answer key.
- A · Context-of-use analysis connects observed conditions to design requirements, evidence boundaries, and change conditions.