Connected Product and Service Design · Study deck
Device Communication: Direct Links
If a product needs a nearby phone, tell users when it needs that phone.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Test direct communication with a concrete scenario and pass criteria.
- Trace try it: audit a communication path claim across its components and failure boundaries.
- Explain: Direct communication can feel immediate when it works, but it can also create setup friction and unclear responsibility.
- Explain: A hub-and-spoke pattern routes devices through a local hub, gateway, bridge, or controller.
Major section
Direct Communication
Local control can reduce delay and keep a simple action near its source.
- Direct communication can feel immediate when it works, but it can also create setup friction and unclear responsibility.
- A motion sensor can reach lights, a thermostat can reach a fan, and a switch can reach bulbs without a cloud round trip.
- The radio labels and ranges make each link a separate installed context check, not one universal distance guarantee.
Major section
Hub-And-Spoke Communication
A hub-and-spoke pattern routes devices through a local hub, gateway, bridge, or controller.
- The hub can coordinate automation, translate protocols, keep local state, and offer a single control point.
- The review should name the single point of failure and the intended fallback before deployment.
- Sensors send events to the central hub, where the device registry and automation rules decide which action to request.
Major section
Mesh Communication
A mesh pattern allows some nodes to relay messages for others.
- Mesh networking should not be treated as automatic reliability.
- A mesh is only as useful as its installed routing nodes, commissioning process, monitoring, and maintenance practice.
- The stated total range of about 30 m therefore depends on router placement and an alternate path, which is exactly why commissioning evidence must include failure recovery rather than coverage alone.
Major section
Cloud-Mediated Communication
Some products route commands, state, and automation through a cloud service even when devices are physically nearby.
- Cloud mediation can support remote access, account policy, fleet monitoring, integration, and cross-site management.
- Cloud mediation is not wrong, but hidden cloud dependency creates poor UX.
- Local controls, safety functions, and recovery paths should be explicit when they exist.
Major section
Hybrid Topologies
Most real IoT systems are hybrid.
- A battery sensor may send to a nearby router, routers may form a mesh, a gateway may run local automations, and the gateway may synchronize with the cloud for remote access and fleet management.
- A hybrid system needs a plain-language operating model.
- Users and support staff should know which parts work locally, which parts need the cloud, and what to do when a path is degraded.
Major section
Communication Pattern Readiness Record
Control owner: where rules, permissions, state, logs, and retries are decided.
- The normal route reaches an end device through several hops, but an average hop distance is not a measurement of every radio link.
- The failed N4 route is the stronger check: N6 must be a powered router that can carry the reroute, while a sleeping end device cannot take that job.
- Failure behavior: user message, degraded function, retry rule, local fallback, manual action, and support evidence.
Major section
Building Lighting Retrofit
A retrofit project adds connected switches and occupancy sensors across many rooms.
- Users expect wall controls to work immediately, facility staff expect central schedules, and support needs a way to locate weak rooms.
- which controls work locally if the internet connection is down.
- whether automations run in the hub, gateway, controller, or cloud.
Major section
Common Findings
The pattern is named by protocol instead of by actual command and state paths.
- Local control is claimed but automation rules depend on the cloud.
- A hub is required but the setup flow presents it as optional.
- Device state in the app has no age, confidence, or last-seen evidence.
- A direct setup path bypasses ownership, logging, or support records.
Major section
Try It: Audit a Communication Path Claim
User outcome: the command, status, alert, automation, or maintenance action the pattern must support.
- Decision owner: where rules, permissions, authoritative state, acknowledgements, retries, and logs are decided.
- Outage behavior: what still works if the phone leaves, the hub restarts, the internet fails, or the cloud is delayed.
- Support evidence: the signal that separates power, radio, hub, gateway, internet, cloud, account, and firmware failures.
Deck summary
Key takeaways
Local control can reduce delay and keep a simple action near its source.
- A hub-and-spoke pattern routes devices through a local hub, gateway, bridge, or controller.
- A mesh pattern allows some nodes to relay messages for others.
- Some products route commands, state, and automation through a cloud service even when devices are physically nearby.
- Most real IoT systems are hybrid.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A product page says a door sensor supports local control, but the review shows that alerts and automations stop whenever the internet connection is down. How should reviewers address the claimed local-control behavior during an outage?
Show answer
Answer: C Communication-pattern review separates the physical path from the decision path so local-control claims match actual user outcomes.
Print reference
Answers
Answer key.
- C · Communication-pattern review separates the physical path from the decision path so local-control claims match actual user outcomes.