UX Design · Study deck
IoT Interaction Design: Discovery Through Release
An IoT interface starts with the user's setting and constraint.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Scenario: a shared building product lets residents unlock a door with a phone, but setup failures are common when an invite expires, the wrong unit is selected, or the reader is temporarily offline.
- Explain: Connected products often have more than one possible interaction path: physical control, app flow, spoken prompt, local indicator, printed setup code, support workflow, automation rule, or maintenance tool.
- Explain: observing different users and contexts. Generating alternative interaction paths. Exploring physical, mobile, voice, support, and automation surfaces. Trying low-cost prototypes that answer different questions.
- Explain: Ideation deliberately separates idea generation from selection.
Major section
Ideate Alternatives
Ideation deliberately separates idea generation from selection.
- Connected products often have more than one possible interaction path: physical control, app flow, spoken prompt, local indicator, printed setup code, support workflow, automation rule, or maintenance tool.
- The point is not to generate novelty for its own sake.
- The point is to avoid false certainty.
Major section
Divergent and Convergent Work
observing different users and contexts. Generating alternative interaction paths. Exploring physical, mobile, voice, support, and automation surfaces. Trying low-cost prototypes that answer different questions.
- selecting the problem frame. Choosing the simplest useful prototype. Deciding which evidence matters. Accepting, rejecting, or revising a design path. Recording owners and change conditions.
Major section
Incremental Examples
Scenario: a shared building product lets residents unlock a door with a phone, but setup failures are common when an invite expires, the wrong unit is selected, or the reader is temporarily offline.
- The review should reject a process that jumps directly to app screens without testing device feedback, offline behavior, role boundaries, or support evidence.
- Scenario: a pump monitor sends maintenance alerts.
- Scenario: an industrial gateway receives an over-the-air firmware update.
Major section
Incremental Examples (continued)
The review should reject a process that treats the update as a single success message.
- Operators complain that alerts arrive too often and do not explain whether action is urgent, assigned, snoozed, repeated, or resolved.
- The review should reject a process that only changes colors or notification wording without checking alert ownership, state, repetition, recovery, and escalation.
- The design path is not ready until users and support staff can see the same update state and recovery boundary.
Major section
Process Record
discovery evidence. Design question. Alternatives considered. Prototype fidelity and scope. Test task and observed behavior. Decision made. Accepted tradeoff. Owner. Open issue. Change condition.
- The record should be short enough to maintain and specific enough to guide the next iteration.
Major section
Micro-Exercise: Choose the Loop Point
For each situation, write which stage should happen next: discover, define, ideate, prototype, test, iterate, or release.
- A smart-lock team knows setup fails when the reader is offline, but no one has observed whether residents understand the offline message.
- A pump-monitoring team has three alert concepts, but has not compared local indicator, mobile notification, dashboard queue, and maintenance-ticket paths.
- A gateway-update flow works in the happy path, but support cannot see firmware version, rollback state, or command correlation id.
Try it: Micro-Exercise: Choose the Loop Point in the chapter
Deck summary
Key takeaways
Ideation deliberately separates idea generation from selection.
- observing different users and contexts. Generating alternative interaction paths. Exploring physical, mobile, voice, support, and automation surfaces. Trying low-cost prototypes that answer different questions.
- Scenario: a shared building product lets residents unlock a door with a phone, but setup failures are common when an invite expires, the wrong unit is selected, or the reader is temporarily offline.
- The review should reject a process that treats the update as a single success message.
- discovery evidence. Design question. Alternatives considered. Prototype fidelity and scope. Test task and observed behavior. Decision made. Accepted tradeoff. Owner. Open issue. Change condition.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team prototypes a polished mobile setup flow for a shared door reader, but testing never includes expired invites, wrong-unit selection, reader offline state, installer recovery, or support handoff. What is the strongest process critique?
Show answer
Answer: B The process is weak when it tests only the happy path.
Print reference
Answers
Answer key.
- B · The process is weak when it tests only the happy path.