UX Design · Study deck
IoT Interaction Principles: State and Evidence
A smart lock must show whether a tap was sent, accepted, or acted on.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- explain core interactive design principles for IoT products
- connect each principle to reviewable evidence from users, context, prototypes, logs, and support scenarios
- identify weak interactions where state, feedback, control, recovery, or trust is hidden
- review IoT setup, notification, and device-control interactions without relying on unsupported claims
Major section
A Clear First Route
The design must show what the system is doing and what the person can do next.
- This page starts with one job.
- Last, choose confirm, wait, retry, undo, seek help, or use a safe manual path.
- A polished screen can still hide a stale state or trap a person after a fault.
- A person may inspect the site.
Major section
A Clear First Route (continued)
This first route is a guide to the main choice.
- The Practitioner sections add review methods, state rules, context tests, feedback, consent, and worked flows.
- Under the Hood adds state authority, timing, cross-device drift, rare faults, and trust after recovery.
- They do not reverse its main claim.
- A local rule may hold a safe state.
Major section
A Clear First Route (continued)
If two sources differ, keep that fact in the record.
- A late result may be true about the past and still be unsafe now.
- A missing result is also useful news when the system shows it at once.
- A remote team may ask for more proof.
- The right step depends on the claim that was tested.
Major section
A Clear First Route (continued)
The first view should show what happened, when it happened, and what is known now.
- It must not depend on a broad product label.
- A sound design still has to work on a bad day.
- The user may be tired.
- The room may be loud or dark.
Major section
A Clear First Route (continued)
A device may be low on power.
- A link may come and go.
- Two records may reach the screen in the wrong order.
- It should not make the user decode a long list before taking a safe step.
- Each answer should be easy to find.
Major section
A Clear First Route (continued)
Trust grows when the system admits its bounds.
- Retest after a change to the device, site, rule, link, or owner.
- The simple story is not a claim that the work is simple.
- End with an owned act and a clear limit.
- The system shows that it heard.
Major section
In 60 Seconds
The principles are not decoration rules.
- Context evidence shows who uses the system, where it is used, what else competes for attention, and what can fail.
- Visible state shows current, pending, stale, offline, uncertain, and rejected states without pretending the system knows more than it does.
- User control keeps important physical actions, permissions, notifications, and overrides understandable.
Major section
Principles Protect Interaction
A clear screen can still be a poor interaction if it hides stale sensor data, delays a command without feedback, or gives a user no local recovery path when the internet connection is down.
- A door unlock request, irrigation override, pump alarm, wearable consent prompt, or room-occupancy dashboard all need different visibility, control, recovery, and privacy choices.
Major section
Principles Protect Interaction (continued)
For principles protect interaction,: Add activity logs supplies visible evidence; is OFF; discrepancy constrains the decision.
- The principle is useful only when it changes what the team designs or tests.
- For that reason, interaction principles should be reviewed as a chain from evidence to behavior.
- Visible state prevents the product from overstating certainty.
Major section
Principles Protect Interaction (continued)
Together,: Add activity logs and is OFF; discrepancy frame the principles protect interaction claim: interaction principles become operational when common failure modes are converted into visible state, recovery paths, setup guidance, and shared-use evidence.
- Feedback closes the loop after the user acts.
- Control and recovery keep the person from being trapped by cloud, account, permission, or sensor failure.
- Accessibility and trust checks keep the result usable in the physical setting, not only in a design review meeting.
Major section
Tie Principles to Mechanisms
For a room occupancy card, rows might cover fresh sensor event, stale last-known event, gateway offline, conflicting sensors, manual override, privacy-restricted room, and support escalation.
- For setup flows, that may include BLE advertising state, QR-code setup payloads, Matter commissioning windows, Wi-Fi provisioning, OAuth consent, and account role assignment.
- The output should be visible in the prototype and in implementation artifacts.
- A practical review table usually has one row per critical state transition.
Major section
Tie Principles to Mechanisms (continued)
That table keeps the design from drifting when the same state appears in a dashboard, mobile notification, device LED, and support console.
- For live operation, it may include MQTT retained messages, device-shadow desired and reported state, command acknowledgements, event timestamps, Web Push, Firebase Cloud Messaging, Apple Push Notification service, SMS fallback, or local LED/haptic feedback.
- A Figma flow, ESP32 bench rig, Home Assistant automation, Node-RED dashboard, support console, OpenAPI endpoint, or firmware log can each carry part of the interaction contract if the owner and state rule are explicit.
- A low-fidelity flow can test wording and task sequence.
Major section
Tie Principles to Mechanisms (continued)
Each row should name the user-facing copy, icon or physical cue, data source, freshness limit, retry or override rule, accessibility constraint, telemetry event, and owner.
- A bench rig or simulator can test timing, command acknowledgement, duplicate tap handling, and offline recovery.
- A seeded support-console record can test whether support sees the same stale/offline evidence the user saw.
- If the review cannot point to the artifact that proves a principle, the principle is still only an intention.
Major section
Interaction Quality Needs State
A dashboard says a room is clear because an occupancy model inferred it, while the gateway is offline.
- A notification says a pump fault is urgent, while the sensor confidence is low and the maintenance role is off shift.
- Designers need enough implementation detail to avoid these mismatches.
- The vocabulary starts with a state hierarchy.
Major section
Interaction Quality Needs State (continued)
Command ids, idempotency keys, sequence numbers, acknowledgements, retained MQTT state, device-shadow version numbers, clock skew, battery thresholds, retry budgets, firmware rollback state, and support correlation ids all affect what the user should see.
- Under-the-hood review does not turn designers into backend owners; it gives the interaction a truthful vocabulary.
- A commanded value is what the cloud or gateway sent.
- An applied value is what the device confirmed.
Major section
Interaction Quality Needs State (continued)
A displayed value is what the interface currently shows.
- Implementation choices decide whether the interface can tell that truth.
- MQTT quality of service and retained messages affect what a reconnecting client may believe.
- Device-shadow versions and ETags help reject stale updates.
- Idempotency keys stop duplicate taps from becoming duplicate physical actions.
Major section
Interaction Principle Map
Early User Involvement beside: Interactive Design so interaction principle map remains explicit.
- In Figure: IoT interaction principle review map, retain: Access trust beside: Feedback so interaction principle map remains explicit.
Deck summary
Key takeaways
The design must show what the system is doing and what the person can do next.
- This first route is a guide to the main choice.
- If two sources differ, keep that fact in the record.
- The first view should show what happened, when it happened, and what is known now.
- A device may be low on power.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team is reviewing a smart-building dashboard that shows an occupied room even when the gateway is offline. Which review record is strong enough to guide the interaction fix?
Show answer
Answer: A A reviewable IoT UX decision ties the person, task, context, touchpoints, connected states, feedback, recovery, constraints, validation evidence, and change condition together before the design is trusted.
Print reference
Answers
Answer key.
- A · A reviewable IoT UX decision ties the person, task, context, touchpoints, connected states, feedback, recovery, constraints, validation evidence, and change condition together before the design is trusted.