Connected Product and Service 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.

connected-devicesdevice-boundarydevice-roles

UX Uma, the module guide, in a scene from this chapter.

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

In 60 Seconds · Phoebe's Field Notes: Why the Coin Cell Dies Before Its mAh Run Out

A connected device is the physical part of an IoT system that senses, acts, displays, stores, relays, or controls information at the edge of the physical world.

Fundamental review asks whether those pieces fit the device role.

Major section

Minimum Viable Understanding · Connected Device Boundaries

Connected-device fundamentals are about fit.

Category labels can help organize examples, but they do not prove that a design works.
A connected device is the place where software promises meet the physical world.
Smart watches and fitness trackers share a group, yet each needs its own role and upkeep plan.

Connected-device fundamentals map a smart lock's internal sensor, firmware, radio, input, credential storage, motor, battery, reset path and update behavior against outside phone, controller, bridge, cloud and support dependencies.

Major section

Device Hard-Constraint Review · Trust in State and Services

The accepted device decision should state the tradeoff.

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 coin-cell sensor may accept fifteen-minute freshness to meet a two-year battery target.

Major section

Connected Device Review Map · Device Boundary

The middle checks cover power, connectivity, and compute or storage; each needs evidence from the installed context, including what happens when a link fails.

The final column takes the decision through update, maintenance, and retirement.
Moving across the columns keeps an attractive feature from hiding a service burden.

Connected device fundamentals review map.

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 or code and the reader or scanner that gives it meaning.
The role should match the evidence.

Worked warehouse doorway sensor selection ties role and gateway dependency to battery and freshness evidence, then tests a late-life voltage-drop brownout risk.

Major section

Core Building Blocks · Tradeoffs That Matter

The review should not treat these blocks as independent.

Changing one often changes another.
Connected-device design is usually a set of bounded tradeoffs rather than one perfect answer.
The coin cell sensor gives up fast updates to meet its battery goal.
The mains powered gateway can spend more energy on local storage and fault checks.

Connected-device trade-offs use three bounded decisions: coin-cell freshness against battery life, gateway compute against buffering and diagnosis, and local lock override against cloud-only commands.

Major section

Evidence For Device Claims · Worked Review: Battery Sensor Endpoint

The goal is not to document every implementation detail.

The goal is to make the design decision reviewable.
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.

Device categories help orient examples, but the review still has to name the role, boundary, dependency, and maintenance evidence for the actual device.

Major section

Worked Review: Gateway Device · Connected Device Record

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.
Offline behavior is documented.

Major section

Common Findings · Review Checklist

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 physical part of an IoT system that senses, acts, displays, stores, relays, or controls information at the edge of the physical world.
Connected-device fundamentals are about fit.

Retrieval practice

Recall check 1 of 3

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?

AAn app mockup and setup flow, with no doorway mounting boundary, battery or service evidence, gateway dependency, or stale-data behavior.

BA feature inventory listing automations, alerts, dashboards, setup screens, and support links, without installed-device evidence.

COne online happy-path demo with permissions already granted, while stale, offline, reset, update, and recovery states remain untested.

DA bounded endpoint record with role, boundary, power, stale data, gateway path, owner, and change trigger.

Show answer

Answer: D 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 3

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. Which interpretation of this device record should reviewers accept?

AUse the sensor label because the sensing endpoint also translates, buffers, and forwards the readings.

BGateway: test buffering, translation, identity, updates, and offline service.

CThe exclusion of translation and buffering as implementation details.

DAn enclosure-size choice before testing connectivity or recovery.

Show answer

Answer: B A connected device should be reviewed by its actual role and boundary, not by a simplified category label.

Retrieval practice

Recall check 3 of 3

UX Uma says: answer from memory, then check your reasoning.

Q3A battery sensor starts retrying weak radio messages all day. Which design claim must the team revisit?

AChange the app icon colour because a clearer icon reduces the field sensor's radio battery drain.

BChange measurement units because display units determine the sensing scale's energy cost.

CReduce cloud price because service cost dominates the sensor's energy use during retries.

DBattery life and radio path under observed retry load.

Show answer

Answer: D More radio use changes energy draw, and weak coverage may keep causing retries.

Print reference

Answers

Answer key.

D · 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.
B · A connected device should be reviewed by its actual role and boundary, not by a simplified category label.
D · More radio use changes energy draw, and weak coverage may keep causing retries.