UX Design · Study deck
Context Analysis: Evidence and Constraints
Start by watching the real task.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: For visible, costly, private, security-related, or hard-to-undo actions, the system should expose confidence, ask for confirmation, or preserve an override rather than silently acting on a single context signal.
- Explain: Wet hands, a shared hallway, a caregiver handoff, a poor Wi-Fi zone, a low battery, and an offline gateway are design facts when they change what the user can safely do.
- Explain: A missed reminder may be caused by low volume, hearing loss, quiet hours, notification permission denial, device offline state, stale caregiver view, or an escalation rule that waited too long.
Major section
Start Simple
A louder alert may improve notice but harm privacy.
- More sensing may improve help but collect too much.
- A smart guess may save a step yet fail when roles or routines change.
- This kitchen story cannot represent every person or future setting.
- Those claims need field work with the people affected.
Major section
Start Simple (continued)
The deeper work keeps the simple setting honest rather than treating it as universal.
- The same step may change its meaning.
- A helpful guess must remain easy to undo.
- The same sensor can feel helpful, intrusive, invisible, or unsafe depending on where it is used and who is nearby.
Major section
Context Changes System Behavior
Context-of-use analysis for IoT is not a background paragraph.
- It explains why a connected system needs a different input, output, state model, fallback, support path, or privacy limit in the real setting.
- A useful context finding says which surface carries the user-visible truth when the others disagree.
Major section
Context Changes System Behavior (continued)
Above it,: Context History,: Context Reasoning, and: Prediction manage patterns and conflicts before the: APPLICATION LAYER adapts location services, notifications, or resource behavior.
- Wet hands, a shared hallway, a caregiver handoff, a poor Wi-Fi zone, a low battery, and an offline gateway are design facts when they change what the user can safely do.
- Raw sensor readings do not become trustworthy context by themselves.
- That makes later design, firmware, support, and privacy decisions traceable.
Major section
Context Changes System Behavior (continued)
The same task may involve a physical button, a small device display, a companion app, a voice assistant, a dashboard, a notification, a support console, and a firmware log.
- That upward path shows where an incorrect inference can enter, while the downward configuration and requirements paths show where observed user context must constrain the system.
- A kitchen measurement device shows the difference between context as evidence and context as guesswork.
- Field observation may show wet hands, flour on fingers, steam, background noise, side-angle viewing, limited counter space, and interruptions from other people.
Major section
Context Findings to Requirements
If installers work in cold storage, "works with gloves" should affect button type, target size, confirmation feedback, and installation flow timing.
- If caregivers and residents share responsibility, the requirement should define what each role sees, how acknowledgement works, and what details remain private.
- A row for "shared caregiver status" might specify role visibility, acknowledgement language, stale-state handling, escalation delay, privacy limit, and support-console field.
- Deployment photos can show mounting and reach.
Major section
Context Findings to Requirements (continued)
Each row should have an owner who can change the device, app, service, or support process.
- Wi-Fi RSSI, gateway logs, device-shadow versions, and battery telemetry can explain state reliability.
- Consent notes, account-role configuration, support tickets, and accessibility settings can explain why a technically working feature still fails in context.
- When the team changes a sensor, enclosure, mounting height, app permission, support script, or automation rule, the affected context rows should be retested rather than treated as evergreen research.
Major section
Context Findings Need Handles
Instrumentation should help the team separate user-context failure from system failure.
- A missed reminder may be caused by low volume, hearing loss, quiet hours, notification permission denial, device offline state, stale caregiver view, or an escalation rule that waited too long.
- The context record should point to the observable signal, the user-facing message, and the owner who changes the device, app, service, or support process.
- Operational handles make those boundaries testable.
Major section
Context Findings Need Handles (continued)
Context-aware architecture can help, but it can also hide uncertainty if the interface treats inferred context as fact.
- Sensor data may be raw, aggregated, classified, predicted, stale, missing, private, or contradicted by the user.
- A motion event, phone proximity, ambient sound level, or location geofence is not the same as intent.
- A field trial can pair observation notes with RSSI/SNR, battery voltage, device placement, notification permission, and local event logs.
Major section
Context Findings Need Handles (continued)
For visible, costly, private, security-related, or hard-to-undo actions, the system should expose confidence, ask for confirmation, or preserve an override rather than silently acting on a single context signal.
- A support record can show gateway id, last-seen timestamp, firmware version, queue depth, command result, and account role without exposing unnecessary household or health detail.
- An automation review can record which context signals are authoritative, which are inferred, which expire, and which user action corrects them.
- Change boundary: rerun context analysis when the site, role, sensor, mounting, app permission, firmware behavior, or integration changes.
Major section
Context Is Use Evidence
Context analysis starts with observed use conditions, not with a feature wish list.
- "Users need a smart kitchen dashboard.".
- "During meal preparation, users often have wet or dirty hands, limited attention, background noise, variable lighting, and interruptions from other people.
- It also makes the assumption testable.
Deck summary
Key takeaways
A louder alert may improve notice but harm privacy.
- The deeper work keeps the simple setting honest rather than treating it as universal.
- Context-of-use analysis for IoT is not a background paragraph.
- Above it,: Context History,: Context Reasoning, and: Prediction manage patterns and conflicts before the: APPLICATION LAYER adapts location services, notifications, or resource behavior.
- The same task may involve a physical button, a small device display, a companion app, a voice assistant, a dashboard, a notification, a support console, and a firmware log.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team is reviewing a kitchen measurement device that must work with wet hands, noise, and interrupted attention. Which context record is strong enough to make the design decision reviewable?
Show answer
Answer: A A reviewable context decision ties the person, task, site, touchpoints, environmental constraints, feedback, recovery, validation evidence, evidence boundary, owner, and change condition together before the design is trusted.
Print reference
Answers
Answer key.
- A · A reviewable context decision ties the person, task, site, touchpoints, environmental constraints, feedback, recovery, validation evidence, evidence boundary, owner, and change condition together before the design is trusted.