UX Design · Study deck
Interaction Patterns: State and Feedback
A phone can show success before the device has changed.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Implement Optimistic UI Updates: Provide immediate feedback while commands travel to devices
- Design Distributed State Synchronization: Keep multiple interfaces synchronized with a single source of truth
- Apply Notification Escalation: Create intelligent alert systems that avoid fatigue while ensuring critical events get attention
- Match Feedback to Action Importance: Design appropriate response timing and modality for different action types
Major section
Start With the Decision · Start Simple
A phone can show success before the device has changed.
- The design must separate a request from a confirmed state.
- The button changes colour at once, but the heater has lost its connection and never starts.
- The interface accepts the request.
- The device may confirm the change.
Major section
Make Delay Visible
The interface must respond immediately while staying honest about the final device state.
- The core pattern is not "pretend it worked." It is "acknowledge the intent now, show the pending state clearly, then reconcile with the authoritative device state.".
- For make delay visible, via Cloud supplies visible evidence;: IoT constrains the decision.
Major section
Make Delay Visible (continued)
Together, via Cloud and: IoT frame the make delay visible claim: interaction patterns coordinate feedback across local controls, mobile apps, cloud services, notifications, and support views instead of treating each screen as an isolated interface.
- Good interaction design turns those questions into visible states.
- An optimistic update is one part of that contract.
- The companion pattern is reconciliation.
Major section
Make Delay Visible (continued)
Interaction patterns are therefore product rules for state, timing, escalation, and recovery, not only visual components.
- The person does not care whether a delay came from Wi-Fi roaming, a sleeping radio, a gateway queue, a cloud rule, or a firmware retry.
- Without reconciliation, optimistic UI becomes misleading decoration.
- With reconciliation, the user sees both responsiveness and truth.
Major section
Make Delay Visible (continued)
They care whether their intent was received, whether the physical world is changing, whether they can safely act again, and what to do if the result does not match the request.
- It lets the interface acknowledge a command quickly, usually within a perceptual instant, while marking the result as pending rather than final.
- A thermostat can show the requested temperature immediately but add "sending" until the device reports the applied setpoint.
- A lock can show "locking" and suppress duplicate toggles while still exposing that the bolt is moving.
Major section
Make Delay Visible (continued)
A garage door can show "opening" for the mechanical travel time instead of leaving the button unchanged.
- When the authoritative state arrives, the interface either confirms the optimistic state, corrects it, or explains why it was rejected.
- If a physical panel changes a setpoint, the app, dashboard, voice assistant, and support console need a consistent story.
- If a camera detects motion all day, notification design must separate routine events from unusual events so people do not silence every alert.
Major section
Design State Pairs
Useful columns include trigger, affected device, optimistic copy, disabled or allowed follow-up actions, command id, authoritative event, timeout threshold, rollback state, user-facing explanation, accessibility feedback, and support evidence.
- This table keeps the team from hiding distributed-system uncertainty behind a single spinner.
- For a temperature stepper, the optimistic state might be "72 degrees requested" while duplicate taps are merged for a short debounce window.
- Acceptance criteria should test both speed and honesty.
Major section
Design State Pairs (continued)
The authoritative event might be a reported setpoint from the device shadow, MQTT topic, or WebSocket stream.
- If confirmation does not arrive before the timeout, the UI should show the last known actual value, the requested value, and the next action: retry, queue for later, check connectivity, or use local controls.
- A smart lock test should include the mobile app, the lock reader or keypad, and the support view if support handles failed commands.
- A camera notification test should include phone settings, in-app notification preferences, event history, quiet hours, activity zones, and the escalation rule for night or unknown-person events.
Major section
Design State Pairs (continued)
If the pattern only works on a perfect network with one user and one interface, it is not ready for an IoT product.
- A facilities dashboard test should include a live value, stale timestamp, source device, threshold rule, acknowledgement owner, and exportable incident record.
- A disabled control should explain why it is disabled or expose a nearby status detail.
- A high-priority alert should not rely on sound alone; it should leave a persistent, reviewable state.
Major section
Synchronization as UX Problem
One command now has user-visible states.
- A dashboard, app, physical switch, voice assistant, and support console can all show different truths if freshness, source, ordering, and conflict policy are not visible.
- The implementation needs explicit hooks for those states.
- Command APIs should return a command id or idempotency key so retries do not create extra physical actions.
Major section
Synchronization as UX Problem (continued)
MQTT and WebSocket updates are common ways to push authoritative changes back to interfaces.
- Good UX therefore exposes enough distributed-system behavior for the user to act safely: pending, stale, unreachable, overridden, denied, confirmed, and reverted are different states and need different feedback.
- Ordering is another product concern.
- Notification escalation also depends on implementation detail.
Major section
Synchronization as UX Problem (continued)
Event streams should include device id, sequence number or timestamp, source, desired state, reported state, and error reason.
- MQTT retained messages can help a newly opened dashboard learn the latest reported state, while WebSocket streams can keep browser or mobile sessions synchronized.
- Both still need freshness policy: a retained value from yesterday should not look the same as a value received five seconds ago.
- A dismissed notification is not the same as an acknowledged incident.
Major section
Synchronization as UX Problem (continued)
The UI should render timestamp, connectivity, and source confidence when the distinction changes the user's next action.
- A physical button, mobile app, automation rule, and voice assistant can all send commands close together.
- Last-write-wins may be acceptable for a lamp, but it can be dangerous for heaters, locks, pumps, or access control.
- The interface should expose the result in plain language instead of leaking internal phrases like race condition or stale write.
Major section
Synchronization as UX Problem (continued)
APNs and FCM can deliver push messages, but the product still needs event classification, duplicate suppression, quiet-hours policy, acknowledgement state, escalation timer, digest generation, and audit history.
- A muted camera zone is not the same as a resolved event.
- Logs that include command id, account role, device firmware, gateway id, network status, battery state, retry count, notification severity, and correlation id let support explain what happened without asking the user to reproduce the failure blindly.
- The implementation is doing its job when the interface can be fast, truthful, accessible, and diagnosable at the same time.
Major section
Checkpoint: Delay and Authority · Interaction Pattern Basics
When you tap "turn off lights" on your phone, the command travels over Wi-Fi to a hub, then via Zigbee to the bulb -- a journey that takes 200-500 milliseconds.
- Meanwhile, you are staring at the button wondering if it worked.
- The most important one is optimistic UI: the app immediately shows "lights off" (before the command even reaches the bulb), then quietly confirms or corrects when the real response arrives.
- This chapter covers the patterns that make IoT interfaces feel instant and trustworthy despite the unavoidable network delays underneath.
Major section
Core Interaction Patterns
Network latency is a fundamental challenge in IoT interfaces.
- IoT devices often have multiple interfaces (app, voice, physical controls).
- In Figure: Distributed State Synchronization, retain: Voice beside: Physical so distributed state synchronization remains explicit.
- Single Source of Truth: Device state is authoritative.
- In Figure: Notification Escalation Strategy, retain 2 min beside 1 hour so notification escalation remains explicit.
Major section
Core Interaction Patterns (continued)
Feedback should reflect the consequence and expected duration of an action, not apply the same spinner or alert to everything.
- The timing chart in Figure: Feedback Design Principles aligns urgency, modality, and timing so the interface can set an honest expectation.
- Across Figure: Feedback Design Principles, a Critical safety alert pairs immediate visual, haptic, and sound feedback with a target below 100 ms.
- An: Important device-state change tolerates 100–300 ms but still needs haptic or sound plus visual confirmation.
- The hierarchy links the chapter's interaction patterns to consequence: stronger feedback is reserved for the actions that demand attention fastest.
Deck summary
Key takeaways
A phone can show success before the device has changed.
- The interface must respond immediately while staying honest about the final device state.
- Together, via Cloud and: IoT frame the make delay visible claim: interaction patterns coordinate feedback across local controls, mobile apps, cloud services, notifications, and support views instead of treating each screen as an isolated interface.
- Interaction patterns are therefore product rules for state, timing, escalation, and recovery, not only visual components.
- They care whether their intent was received, whether the physical world is changing, whether they can safely act again, and what to do if the result does not match the request.
Retrieval practice
Recall check 1 of 2
UX Uma says: answer from memory, then check your reasoning.
Q1A tenant taps Heat now and the app changes color before the offline heater responds. What should that immediate feedback mean?
Show answer
Answer: A The chapter separates requested, accepted, confirmed, and observed states.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A remote device has not yet acknowledged an app command. Which interface behavior fits the chapter?
Show answer
Answer: D The pattern acknowledges intent quickly while preserving uncertainty about completion.
Print reference
Answers
Answer key.
- A · The chapter separates requested, accepted, confirmed, and observed states.
- D · The pattern acknowledges intent quickly while preserving uncertainty about completion.