Connected Product and Service 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:
- Translate a product promise into system design views.
- Locate hardware, service, and context risks in a model.
- Explain: Naming these challenges explains why the promise, boundary, view, and evidence discipline in this chapter is not optional overhead.
- 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
Evidence then supports a decision, while the owner makes its acceptance and follow-up accountable.
- Tradeoff and open-issue fields keep rejected strengths and unresolved risks visible.
- The change condition closes the record by naming what must reopen review.
- Promise: user outcome, role, setting, and evidence limit.
- Concern: cross-cutting issue that must be reviewed across boundaries.
Major section
Introductory Design Model Record (continued)
Together, the ten fields turn a diagram from an attractive system picture into a compact decision artifact that another team can test, challenge, and maintain.
- Boundary: devices, software, people, services, support tools, and external systems in scope.
- Evidence: observation, test, support record, technical validation, or risk review.
- Tradeoff: known limit and why it is acceptable now.
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.
- Evidence then supports a decision, while the owner makes its acceptance and follow-up accountable.
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. How should reviewers assess the model's user outcome and outage claims?
Show answer
Answer: D 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.
- D · A useful introductory design model ties components to user promise, responsibility boundaries, failure behavior, support evidence, risks, owners, tradeoffs, and change conditions.