UX Design · Study deck
IoT Architectures: Model Evidence
Picture a school with a room sensor.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- compare simple layered, expanded layered, and multi-view architecture models for IoT design work
- review whether architecture complexity matches user outcomes, system scope, team boundaries, and operational needs
- define layer responsibilities without hiding ownership, failure, privacy, or support evidence
- identify when cross-cutting concerns require explicit review across layers and views
Major section
Start Simple
A small hub sends the reading.
- An app shows it to the site team.
- An architecture model is a plan that puts each system job in a named box.
- A layer is one group of related jobs.
- The plan might give sensing to the device, data transfer to the hub, and the screen to the app.
Major section
Start Simple (continued)
An architecture model becomes a UX tool when it tells the team who owns the user-visible promise.
- Each box needs an owner.
- Each handoff needs a test.
- This turns a diagram into a tool the team can use.
- A larger product may need more.
Major section
Start Simple (continued)
Each need must have an owner at every handoff where it can fail.
- It might split out data work, device care, business rules, or support.
- More boxes do not make a design safer by themselves.
- Some needs cross every layer.
- Security controls who may act.
Major section
Start Simple (continued)
Privacy sets limits on data use.
- Accessibility helps people use the product in different ways.
- The data path runs from a raw reading to the value on screen.
- The simple story here leaves out exact state rules, message formats, and platform choices.
- The Practitioner section shows which design records fit each choice.
Major section
Start Simple (continued)
Under the Hood shows how layers can hold different versions of the same state.
- The user needs a fresh room value.
- The app owns what the user sees.
- The team must name how old a value may be before the app marks it as stale.
- The app records the wish.
Major section
Architecture Models as Risk Filters
An IoT architecture model should expose the risks that matter for a product decision.
- A three-layer view may be enough for a small sensor-gateway-app system.
- A multi-view model is justified when one diagram cannot explain data meaning, deployment placement, identity, operations, and support responsibility at the same time.
Major section
Architecture Models as Risk Filters (continued)
A classroom weather station may only need device, gateway, and application layers.
- The number of architecture layers should follow the decisions that need owners, not a preferred template.
- If alert rules move from a gateway to the cloud, latency, outage behavior, privacy boundary, support logs, and update ownership all change.
- A managed building system may need separate views for edge analytics, tenant identity, role-based access, cloud ingestion, data retention, service desk diagnostics, and facilities handover.
Major section
Architecture Models as Risk Filters (continued)
If device health is hidden inside an application layer, users may see a stale "online" state while support cannot tell whether the fault is power, radio, gateway, broker, cloud, account, or policy.
- A richer model is justified by decisions it makes clearer, not by the number of boxes it contains.
- The architecture review should also name what the model intentionally leaves out.
- A three-layer model can be accepted when it records that firmware updates are manual, alerts are advisory, cloud outage leaves local display working, and support can inspect gateway logs.
Major section
Match Artifacts to Decisions
A C4 context or container view can show people, devices, gateways, apps, brokers, cloud services, and external platforms.
- A UML sequence diagram can test commissioning, command acknowledgement, and rollback timing.
- A UML or SysML state machine can expose offline, stale, denied, overridden, pending, and recovered states.
- Real systems often need mixed views.
Major section
Match Artifacts to Decisions (continued)
If the question is device management, compare LwM2M objects, Matter clusters, vendor device shadows, OTA rollout tooling, and support-console evidence.
- A Matter device may need a cluster/capability view, a fabric and controller ownership view, and a support view.
- An industrial gateway may need OPC UA information modeling, MQTT topic contracts, network segmentation, and maintenance workflow evidence.
- A fleet that adds cellular backhaul may need a deployment and cost view.
Major section
Layers Change State Authority
The authoritative source for a live temperature, an alert threshold, a command acknowledgement, a firmware version, a billing event, and a user role may be different systems.
- The architecture model must say which state is authoritative for each user promise.
- MQTT topics need ownership and quality-of-service rules.
- CoAP resources need response-code handling.
Major section
Layers Change State Authority (continued)
Sensor firmware may hold measured state, a gateway may cache state, an MQTT broker may retain the last message, a digital twin may store desired and reported properties, and an app may display a local cache.
- OPC UA nodes carry industrial information-model meaning.
- Architecture boundaries also decide where errors are translated.
- If the model does not preserve cause, timestamp, source, and retry state across those translations, support teams cannot distinguish a bad sensor, a stale retained message, a policy denial, or a delayed cloud write.
Deck summary
Key takeaways
A small hub sends the reading.
- An architecture model becomes a UX tool when it tells the team who owns the user-visible promise.
- Each need must have an owner at every handoff where it can fail.
- Privacy sets limits on data use.
- Under the Hood shows how layers can hold different versions of the same state.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team is choosing between a simple layered model and an expanded model for a room-monitoring product. Which architecture rationale is strong enough to accept the model?
Show answer
Answer: A Architecture records are useful when they tie model choice to user outcomes, layer responsibilities, data and command paths, cross-cutting ownership, operations evidence, accepted limits, and change conditions.
Print reference
Answers
Answer key.
- A · Architecture records are useful when they tie model choice to user outcomes, layer responsibilities, data and command paths, cross-cutting ownership, operations evidence, accepted limits, and change conditions.