UX Design · Study deck
Device Communication: Pattern Selection
Retell the user path in small steps.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- distinguish direct, hub-and-spoke, mesh, cloud-mediated, and hybrid communication patterns
- review how a communication pattern changes setup, responsiveness, reliability, privacy, and support behavior
- identify where commands, automation rules, state, and logs actually travel
- separate user-visible failure modes from hidden network implementation details
Major section
Start Simple
They need to know whether the door opened, whether the request is still in flight, or whether they should use a key.
- Telemetry means time-stamped reports about device state and events.
- The word protocol means an agreed set of rules for how devices exchange data.
- A direct path may be fast but work only nearby.
- Its storage can fill.
Major section
Start Simple (continued)
A hub can keep local rules running.
- A mesh can route around one gap.
- A cloud path can support remote use but can also be slow or offline.
- A mixed design can use more than one path, but it needs one clear owner for state.
- One protocol name does not answer these questions.
Major section
Start Simple (continued)
It may fail when the phone leaves.
- Practitioner compares setup, delay, power, privacy, support, and recovery.
- Under the Hood explains path and decision ownership, stale state, and split paths.
- Those details can change the user feedback.
- They never make a hidden failure safe to ignore.
Major section
Communication Path Ownership
The protocol label is only one detail.
- The user experience depends on which path is local, which path needs the cloud, which component owns state, and what happens when one segment is degraded.
- Those paths do not have the same latency, privacy boundary, power cost, failure mode, or support owner.
- The pattern also changes who must understand the system.
Major section
Communication Path Ownership (continued)
Users need status that names the action they can take rather than a generic offline label.
- Together,: Owner and offline frame the communication path ownership claim: the pattern decision has to connect the user goal to the command path, state path, decision owner, local/cloud boundary, failure mode, and support record.
- The second may tolerate buffering, sequence numbers, and delayed upload.
- Command path: know where user intent is accepted, queued, authorized, delivered, acknowledged, and confirmed.
Major section
Communication Path Ownership (continued)
For a lighting system, a wall switch may talk directly to a bulb, through a hub, across a Thread or Zigbee mesh, through a building gateway, and then to a cloud dashboard for remote monitoring.
- The third may require account authority, audit logs, rollback, and a clear message when a cloud rule has not reached the local controller.
- Installers need to know which nodes must be powered routers, where the hub or gateway belongs, and how to verify routes after doors, walls, or furniture change.
- Recovery path: know what remains local, what waits, what retries, what alerts, and what support can inspect.
Major section
Map Protocols to Behavior
A Thread sleepy end device may behave well near a border router but fail after a powered router is removed.
- A BLE direct-control path may feel immediate until the phone leaves the room or the device sleeps.
- A cloud-mediated alert may work in the lab but become confusing when local control still works and remote notifications stop.
- The implementation should expose enough diagnostics for support.
Major section
Path vs Decision
A device may use a local radio path but still depend on a cloud decision.
- A hub may receive a command locally but fetch permissions from an account service.
- A mesh may relay packets locally but store schedules in the cloud.
- Good UX depends on separating transport path, authority path, automation path, and support path.
Major section
Path vs Decision (continued)
Observability should preserve path evidence without exposing unnecessary personal data.
- Authority should be explicit in the protocol and data model.
- A local button press, scheduled cloud rule, technician override, mobile app command, and safety interlock can all target the same actuator.
- Authority: separate device identity, user account authority, local override, tenant ownership, and support access.
Major section
Path vs Decision (continued)
The system needs idempotency, command expiry, conflict resolution, replay protection, permission checks, and audit records so delayed or duplicated messages do not create surprising physical behavior.
- If account revocation happens in the cloud, the record should state what local credentials remain valid and for how long.
- Gateways can store sequence numbers, route parents, retry counts, broker disconnect reasons, cloud correlation IDs, clock confidence, firmware versions, and local decision logs.
- Those fields let support distinguish radio coverage, sleeping endpoints, hub storage pressure, internet loss, account failure, and cloud-service outage.
Deck summary
Key takeaways
They need to know whether the door opened, whether the request is still in flight, or whether they should use a key.
- A hub can keep local rules running.
- It may fail when the phone leaves.
- The protocol label is only one detail.
- Users need status that names the action they can take rather than a generic offline label.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A facilities team is choosing how corridor lights, wall switches, occupancy sensors, and a cloud dashboard communicate. Which review record is strong enough to approve the pattern?
Show answer
Answer: A A reviewable communication-pattern decision ties user outcome, participants, paths, decision ownership, local and cloud boundaries, failure behavior, support evidence, owner, accepted limits, and change condition together before the topology is trusted.
Print reference
Answers
Answer key.
- A · A reviewable communication-pattern decision ties user outcome, participants, paths, decision ownership, local and cloud boundaries, failure behavior, support evidence, owner, accepted limits, and change condition together before the topology is trusted.