UX Design · Study deck
Anatomy of a Connected Device
Imagine a door sensor that shows "closed" on a phone.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- define a connected device by role, boundary, inputs, outputs, power, connectivity, and maintenance context
- distinguish endpoint, actuator, gateway, interface, and infrastructure roles in an IoT system
- explain how power, connectivity, sensing, actuation, compute, enclosure, and service constraints interact
- identify evidence needed before accepting a connected-device design claim
Major section
Start Simple
A fault in any one part can make the same screen wrong.
- A connected device is not just hardware with a radio.
- A working app does not prove that the physical state is current, and a cloud reply does not prove that the device can recover safely.
- This keeps the screen tied to the real world.
Major section
Start Simple (continued)
Each crossing adds a need for trust and support.
- It may sense, act, show, store, relay, or guard.
- A gateway and a small end device may share a radio but need very different proof.
- A device that resets during its main action cannot meet the promise shown by its average use.
Major section
Start Simple (continued)
A person near the product should know if it has power, is ready, is offline, needs setup, has rejected a command, or is in a safe fault state.
- A factory label alone does not prove who controls the live product.
- An update path is part of the product, not an extra tool.
- A product is not ready when only its maker can guess what failed.
- New hardware, power, code, network, service, user, or place can all change the result.
Major section
Connected Device Boundaries
A connected device is the place where software promises meet the physical world.
- Together,: Smart Watches and: Wearables frame the connected device boundaries claim: device categories help orient examples, but the review still has to name the role, boundary, dependency, and maintenance evidence for the actual device.
- The same category can hide very different review needs.
Major section
Device Hard-Constraint Review
Useful connected-device review starts with constraints that cannot be solved in the app later.
- Connectivity also has to be checked in the installed context.
- A bench test with the cover open does not prove performance inside a metal cabinet, freezer, basement, moving vehicle, or outdoor enclosure.
- The accepted device decision should state the tradeoff.
Major section
Device Hard-Constraint Review (continued)
For connectivity, record join method, pairing ownership, retry limit, queue behavior, stale-data rule, local fallback, gateway dependency, and what the receiving system can distinguish.
- For compute and storage, record which rules run locally, what survives restart, which data is buffered, and how firmware updates are staged and rolled back.
- A gateway should be tested with endpoint churn, local-protocol errors, clock drift, offline buffering, backhaul recovery, and partial failure displayed to support staff rather than hidden behind a single online status.
- A coin-cell sensor may accept fifteen-minute freshness to meet a two-year battery target.
Major section
Trust in State and Services
Each item needs a lifetime, reset rule, and protection level that matches the device role.
- A connected device becomes trustworthy when its local state is explicit.
- Firmware should separate sensed value, command intent, actuator result, radio status, time source, configuration version, update slot, and fault reason instead of collapsing everything into "online" or "working.".
- If those states are implicit, field failures become ambiguous and recovery procedures become unsafe.
Major section
Trust in State and Services (continued)
Internal flash, FRAM, EEPROM, a secure element such as ATECC608A, or a TPM-class module may hold keys, counters, calibration, boot flags, rollback images, or pairing secrets.
- A device may move through manufactured, provisioned, commissioned, normal, degraded, offline, updating, rollback, factory-reset, ownership-transfer, and retired states.
- Each state should define what commands are accepted, which credentials are active, which data is retained, whether actuation is allowed, how the user sees the condition, and what support can inspect.
- A gateway that keeps accepting endpoint commands while its cloud path is down may create stale automation.
Major section
Trust in State and Services (continued)
Storage choices matter because device history may survive loss of power, ownership transfer, or a failed update.
- They may track endpoint membership, local network health, backhaul reachability, clock confidence, translation errors, buffer pressure, duplicate suppression, schema versions, tenant or site binding, and update compatibility.
- A gateway that drops buffered data silently may turn a local radio fault into a misleading cloud dashboard.
- The low-level implementation evidence should connect back to the user-facing promise.
Major section
Trust in State and Services (continued)
Observability:: Preserve enough counters, timestamps, firmware versions, and fault codes for support to distinguish device, gateway, and service failures.
- If a device promises reliable occupancy status, its firmware must show sample timestamps, debounce rules, confidence or stale flags, retry behavior, and receiver semantics.
- If a device promises remote control, it must show authorization, command expiry, idempotency, result confirmation, and local safe state.
- If a device promises easy service, it must show reset paths, diagnostic codes, update rollback, replacement identity, and decommissioning behavior.
Major section
Device Roles
A connected device may have one primary role or several roles combined.
- The "device" a user or operator reasons about is really the pairing of the passive tag and the reader, scanner, or beacon-listening app that gives it meaning.
- The role should match the evidence.
Major section
Tradeoffs That Matter
Connected-device design is usually a set of bounded tradeoffs rather than one perfect answer.
- Connectivity versus installation: A radio that works well on a bench can fail after the device is mounted near metal, the body, water, machinery, walls, or underground material.
- Cloud-dependent behavior can simplify the device, but it needs offline and recovery evidence.
Major section
Worked Review: Battery Sensor Endpoint
A small endpoint samples a physical condition and reports values through a gateway.
- Sensor placement and sampling purpose are clear.
- The receiver can distinguish fresh, stale, duplicate, and missing values.
- The sleep, wake, transmit, and retry behavior fits the service interval.
- The gateway dependency is recorded.
Major section
Worked Review: Gateway Device
The gateway update path does not strand endpoints.
- A gateway aggregates nearby device traffic and forwards selected data to another system.
- The gateway role is separated from the endpoint roles.
- Protocol translation and buffering rules are visible.
- Local time, identity, and configuration ownership are clear.
Major section
Connected Device Record
Role and boundary: what the device is responsible for and where that responsibility ends.
- Decision and change control: accepted tradeoff, owner, known limit, open issue, and trigger.
Major section
Common Findings
The design uses a category label instead of a role and boundary record.
- Connectivity was tested only before installation.
- Sensor or actuator behavior is described without receiver or safe-state evidence.
- Maintenance depends on tools, access, or permissions that are not recorded.
- The record lacks a change condition after radio, battery, enclosure, firmware, gateway, or deployment changes.
Deck summary
Key takeaways
A fault in any one part can make the same screen wrong.
- Each crossing adds a need for trust and support.
- A person near the product should know if it has power, is ready, is offline, needs setup, has rejected a command, or is in a safe fault state.
- A connected device is the place where software promises meet the physical world.
- Useful connected-device review starts with constraints that cannot be solved in the app later.
Retrieval practice
Recall check 1 of 2
UX Uma says: answer from memory, then check your reasoning.
Q1A team is reviewing a battery sensor endpoint for a warehouse doorway. Which record is strong enough to make the device decision reviewable?
Show answer
Answer: A A reviewable connected-device decision ties the role, boundary, inputs, outputs, power, connectivity, local behavior, maintenance evidence, owner, known limit, and change condition together before the design is trusted.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A design record calls a device a simple sensor, but it also buffers data, translates local messages, updates endpoint configuration, and forwards data to the cloud. What is the strongest review response?
Show answer
Answer: A A connected device should be reviewed by its actual role and boundary, not by a simplified category label.
Print reference
Answers
Answer key.
- A · A reviewable connected-device decision ties the role, boundary, inputs, outputs, power, connectivity, local behavior, maintenance evidence, owner, known limit, and change condition together before the design is trusted.
- A · A connected device should be reviewed by its actual role and boundary, not by a simplified category label.