Human-Centred IoT Design · Study deck
User Research Fundamentals for IoT
Start with a person doing a real task, not with a feature list.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A first research pass for a home leak sensor can observe three things: where people place the sensor, how they test reachability, and what they think the LED or app status means.
- Explain: A smart-lock team might learn that residents understand the app invitation but visitors still wait outside because the reader, push notification, and support script describe different states.
- Explain: BLE or NFC credential state, reader firmware, app event names, push-notification permission, and support tags can explain why a person repeats an invite or calls support.
- Explain: Each pass can change the original decision.
Major section
IoT Research Beyond Screens
A smart-lock team might learn that residents understand the app invitation but visitors still wait outside because the reader, push notification, and support script describe different states.
- IoT user research studies people, places, devices, services, and support paths together.
- Each pass can change the original decision.
- Those moments are the evidence that screens alone cannot provide.
Major section
IoT Research Beyond Screens (continued)
A setup screen can look clear in a conference room but fail on a porch at night, beside a metal equipment cabinet, in a shared apartment, or during a maintenance visit with weak connectivity.
- Observation captures what people do in context; interpretation explains what that behavior may mean without treating one visit as universal proof.
- A requirement turns the finding into a testable behavior, and the retest trigger says when new evidence is needed.
- Without that loop, a field visit can become a list of anecdotes rather than a decision record.
- For connected products, the useful observation often sits between human action and system state.
Major section
IoT Research Beyond Screens (continued)
A participant may say the leak sensor is easy to set up while repeatedly moving it away from the likely leak path.
- A nurse may acknowledge an alert but still rely on hallway routines because the wearable data is not trusted.
- People: Include the account owner, daily user, visitor, installer, technician, support agent, bystander, or operator affected by the design.
- Context: Observe lighting, noise, reach, weather, phone permissions, shared ownership, privacy expectations, and accessibility needs.
Major section
Field Observation with Device Logs · Research Findings Need Boundaries
A useful research plan pairs human observation with system traces.
- Field notes may show that a resident taps "unlock" repeatedly, while device logs show BLE reconnect delays, gateway timeouts, or a cloud authorization failure.
- Neither source is enough by itself.
- Contextual inquiry can reveal installation and maintenance problems.
Major section
Field Evidence to Decisions · Why User Research Matters
Observe the task where the physical, social, and technical constraints are visible.
- Translate the finding into a checkable requirement: The requirement should name the state, role, context, and acceptance condition.
- IoT design often fails when a technically correct system does not match the user's real situation.
- A setup flow works in the lab but fails on a dim porch with weak connectivity.
Major section
Evidence-First Research Loop · Evidence to Requirements Chain
Example: "The setup flow must distinguish device offline, app permission denied, and invite pending before field pilot review.".
- Observation: What was seen, heard, logged, or recorded.
- Interpretation: What the team thinks the observation means.
- Example: "Participants may not trust the app state until the device state is visible.".
Major section
The Curse of Knowledge · Stated Preference and Revealed Behavior
The curse of knowledge happens when experts forget what it is like not to know what they know.
- "What would this screen, alert, or device state mean to someone seeing it for the first time while doing the real task?".
- Neither source should erase the other.
- Stated preference is not useless.
Major section
Context Changes the Design · Users and Affected Roles
The same user may behave differently depending on context.
- Physical: space, lighting, noise, weather, reach, mounting, cleaning, power, and placement.
- Social: alone, shared household, workplace, visitor, caregiver, technician, manager, or support agent.
- Temporal: routine, time pressure, emergency, night, shift work, seasonal use, or long-term maintenance.
Major section
From Research Question to Evidence · Write Better Research Questions
A resident sees 'not available' and retries an invite while a visitor waits at the shared entrance.
- That trace lets reviewers challenge the interpretation without losing the original user and support evidence.
- "Do users like the product?".
- "Can a first-time resident understand whether a failed shared-entry setup is caused by phone permission, device offline state, invite status, or account ownership?".
- "Would people use automation?".
Major section
Incremental Examples
A first research pass for a home leak sensor can observe three things: where people place the sensor, how they test reachability, and what they think the LED or app status means.
- The team can pair field notes with app events, Wi-Fi RSSI, battery state, firmware version, and the last successful alert timestamp.
- A shared-entry product needs research across residents, visitors, installers, and support staff.
- The requirement should separate what residents can fix from what support must own.
Major section
Incremental Examples (continued)
The design decision might be whether setup should show "reachable here", "move closer to gateway", or "test with water" before the device is trusted.
- Observations should cover pending invites, revoked credentials, denied phone permissions, reader offline state, and support handoff.
- BLE or NFC credential state, reader firmware, app event names, push-notification permission, and support tags can explain why a person repeats an invite or calls support.
- A cold-chain monitoring study may involve operators, quality staff, maintenance technicians, and external auditors.
Major section
Research Fundamentals Checklist · Common Defects
Observation drift: writing interpretation as if it were observed fact.
- Designing for ourselves: assuming the team's knowledge, devices, habits, and patience match the user's.
- Context omission: testing in clean conditions when real use is noisy, rushed, shared, dark, wet, mobile, or interrupted.
- Happy-path evidence: ignoring failure, maintenance, transfer, support, and removal.
Major section
Try It Now · Separate Research Claims
"Users ignored the maintenance alert, so they need a bigger red banner.".
- "Do users like alerts?".
- A stronger question should name the role, context, alert state, decision to be made, evidence source, and action the team may take.
- The observation should say what was seen.
Deck summary
Key takeaways
A smart-lock team might learn that residents understand the app invitation but visitors still wait outside because the reader, push notification, and support script describe different states.
- A setup screen can look clear in a conference room but fail on a porch at night, beside a metal equipment cabinet, in a shared apartment, or during a maintenance visit with weak connectivity.
- A participant may say the leak sensor is easy to set up while repeatedly moving it away from the likely leak path.
- A useful research plan pairs human observation with system traces.
- Observe the task where the physical, social, and technical constraints are visible.
Retrieval practice
Recall check 1 of 3
UX Uma says: answer from memory, then check your reasoning.
Q1A team is deciding how a shared-entry app should explain failed visitor invites after observing residents, visitors, and support staff. Which research record is strong enough to guide the design?
Show answer
Answer: C A reviewable IoT user-research record ties the design decision to roles, context, observations, interpretation, evidence boundary, requirement, validation, owner, and change condition before the finding is trusted.
Retrieval practice
Recall check 2 of 3
UX Uma says: answer from memory, then check your reasoning.
Q2A setup screen says “refresh your broker token,” and new users cannot finish pairing. What research risk does this show?
Show answer
Answer: C The team assumed users know its internal terms and should test task language with fresh users.
Retrieval practice
Recall check 3 of 3
UX Uma says: answer from memory, then check your reasoning.
Q3A team says users want a detailed sensor dashboard because interview participants said it sounded useful. In field observation, people only check whether the device is ready, stale, offline, or needs action. What should the team conclude?
Show answer
Answer: B User research fundamentals require separating stated preference from observed behavior and turning evidence into testable requirements.
Print reference
Answers
Answer key.
- C · A reviewable IoT user-research record ties the design decision to roles, context, observations, interpretation, evidence boundary, requirement, validation, owner, and change condition before the finding is trusted.
- C · The team assumed users know its internal terms and should test task language with fresh users.
- B · User research fundamentals require separating stated preference from observed behavior and turning evidence into testable requirements.