UX Design · Study deck
IoT Design Models: Product and System Decisions
A connected product joins a device, service, user, and operating setting.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: extra layers have no unique decisions. Teams debate labels more than behavior. Every box passes responsibility to another box. Diagrams are maintained separately from the real implementation. Users and support teams still cannot explain what failed.
- Explain: A smart home security system is one product but four technical layers: door sensors as the device layer, Wi-Fi as connectivity, cloud processing as the backend, and a mobile app as the interface.
- Explain: A smart thermostat has to account for home layout, HVAC behavior, and wall placement while still running a temperature-optimization algorithm.
Major section
Why IoT Design Differs From Software Design
Naming these challenges explains why the promise, boundary, view, and evidence discipline in this chapter is not optional overhead.
- A smart home security system is one product but four technical layers: door sensors as the device layer, Wi-Fi as connectivity, cloud processing as the backend, and a mobile app as the interface.
- The model should show how the team keeps those layers consistent, tolerates network latency and failure, synchronizes state across devices, and lets support diagnose an issue that spans more than one layer.
- Physical-digital integration.: Physical constraints shape digital choices, and digital capability changes what the physical device must do.
Major section
Why IoT Design Differs From Software Design (continued)
A smart thermostat has to account for home layout, HVAC behavior, and wall placement while still running a temperature-optimization algorithm.
- Longevity and evolution.: Hardware can stay in service for years while the software and cloud services underneath it change.
- A smart speaker bought several years ago still has to work with current voice assistants and protocols.
- The record should show which tradeoff was accepted and why, not just the final sampling rate.
Major section
Choose The Lightest Useful Model
A simple model is often enough when responsibilities are clear.
- Additional layers or views are useful only when they help decisions.
- extra layers have no unique decisions. Teams debate labels more than behavior. Every box passes responsibility to another box. Diagrams are maintained separately from the real implementation. Users and support teams still cannot explain what failed.
- The right model is the lightest one that makes responsibility and recovery clearer.
Major section
Review Cross-Cutting Concerns
Some concerns are not owned by one layer or one component.
- Privacy: collection, consent, visibility, sharing, retention, deletion, and support access.
- Safety: local control, fail-safe behavior, physical effects, warnings, and override.
- Accessibility: setup, indicators, alerts, controls, language, physical reach, and support.
- Observability: logs, health signals, support evidence, user-visible status, and incident records.
Major section
Introductory Design Model Record
Promise: user outcome, role, setting, and evidence limit.
- Boundary: devices, software, people, services, support tools, and external systems in scope.
- Concern: cross-cutting issue that must be reviewed across boundaries.
- Evidence: observation, test, support record, technical validation, or risk review.
- Decision: what was accepted, changed, deferred, simplified, or sent back for more evidence.
Major section
Common Findings
The model starts with a preferred technology instead of the product promise.
- Layers are named but not owned.
- Data freshness, inference, and uncertainty are hidden.
- Cross-cutting concerns are placed in one box instead of reviewed across boundaries.
- Failure behavior is discussed after the architecture is treated as final.
Deck summary
Key takeaways
Naming these challenges explains why the promise, boundary, view, and evidence discipline in this chapter is not optional overhead.
- A smart thermostat has to account for home layout, HVAC behavior, and wall placement while still running a temperature-optimization algorithm.
- A simple model is often enough when responsibilities are clear.
- Some concerns are not owned by one layer or one component.
- Promise: user outcome, role, setting, and evidence limit.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team presents a polished IoT architecture diagram with sensors, gateway, cloud, and dashboard boxes. The diagram does not say what user outcome is promised, who owns stale data, what happens when the gateway is offline, or how support diagnoses failures. What is the strongest review response?
Show answer
Answer: B A useful introductory design model ties components to user promise, responsibility boundaries, failure behavior, support evidence, risks, owners, tradeoffs, and change conditions.
Print reference
Answers
Answer key.
- B · A useful introductory design model ties components to user promise, responsibility boundaries, failure behavior, support evidence, risks, owners, tradeoffs, and change conditions.