UX Design · Study deck
IoT Design Facets: Surfaces and Interaction
This first route frames the eight-facet review and follows the visible product surfaces and interactions.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- explain the 8 facets as a visible-to-hidden review model for IoT products
- connect each facet to evidence, risk, owner, and user impact
- identify gaps caused by focusing only on UI or hardware appearance
- review interusability, conceptual models, service workflows, product promises, and platform responsibilities
Major section
Ubiquitous Computing Roots
In an IoT review, that idea is practical.
- A phone, wall display, web dashboard, voice interface, wearable, tablet, and support console may all show state or offer control.
- Routine awareness can live at the edge of attention.
- Risk, uncertainty, and action can move to the surface where the right person can respond.
Major section
Ubiquitous Computing Roots (continued)
The classic ubiquitous-computing scale of tabs, pads, and boards still helps review IoT products.
- Small personal devices such as phones and tags fit quick glance, identity, and private confirmation tasks.
- Pad-sized surfaces fit inspection, setup, and richer comparison.
- Room-scale boards and shared displays fit collaborative awareness, teaching, operations, and local status.
Major section
Ubiquitous Computing Roots (continued)
Proximity might suppress a notification, change display behavior, or infer attention.
- The same product may need all three scales, but each scale should carry the part of the task it is best suited to carry.
- A tilt sensor might support orientation or gesture.
- Touch around the device body might reduce screen clutter.
Major section
Ubiquitous Computing Roots (continued)
Proximity sensors, touch-sensitive bezels or device sides, and accelerometers can make interaction more context-aware, but only when the product explains what those signals mean.
- The design review should name the sensed condition, the inference, the user benefit, the failure case, and the fallback when the signal is wrong.
- A release-ready calm design records the place granularity, receiver or line-of-sight assumptions, activity label, confidence, retention policy, and fallback when the context guess is wrong.
- That shift matters because connected products often have overlapping capabilities.
Major section
Facets Link Polish to Truth
The eight facets help a team review a connected product from what people see to what the platform must own.
- A polished app, clean enclosure, or friendly notification can still fail if state is stale, permissions are unclear, support cannot diagnose a failure, or the platform cannot keep the product promise.
Major section
Facets Link Polish to Truth (continued)
For a shared-room sensor, the UI label, wall-device placement, app workflow, dashboard state, support handoff, product claim, and cloud dependency all describe the same experience.
- Reviewing only one facet misses how the system behaves when motion is inferred, a phone app is stale, the gateway is offline, or ownership changes.
- The facets are not a checklist of equal-sized boxes.
- A strong review records evidence for each layer of the experience.
Major section
Test Facets Against Failures
UI may own the status label, but platform may own the freshness timestamp and retry state.
- IP rating, battery access, reset reach, label durability, and sensor line-of-sight matter for industrial design.
- In each case, record whether the facet gives a user, installer, operator, or support agent enough information to act.
- Service design may own the support script, but firmware and cloud teams may own OTA status, reset reason, and decommissioning evidence.
Major section
Calm Behavior Needs System State
Calm technology is a platform and service decision as much as a visual design decision.
- A notification can be calm only if the system knows state freshness, severity, actionability, ownership, and escalation route.
- BLE or QR onboarding affects service design.
- Firmware OTA behavior affects support workflow and product trust.
- Local fallback affects productization claims.
Major section
Calm Behavior Needs System State (continued)
Device telemetry affects whether the UI can safely say "available," "occupied," "offline," or "unknown.".
- The calmness rule needs data provenance.
- A PIR sensor event, door sensor event, manual override, camera-derived inference, reservation-system update, retained MQTT message, cloud shadow value, and dashboard cache can all describe a room differently.
- Escalation should be role-aware.
- Without those facet-specific responses, calm design becomes either silence or noise.
Major section
Calm Behavior Needs System State (continued)
The platform has to carry timestamps, source, confidence, account role, and override state so the UI can avoid false certainty and support can explain why two surfaces disagree.
- A low battery may need a quiet status for an occupant, a scheduled task for facilities, and an urgent warning for support if the device is safety-critical.
- A gateway outage may need local display fallback, a dashboard degraded-state banner, an installer diagnostic path, and a product claim that admits the cloud dependency.
- Otherwise it either stays quiet when action is needed or interrupts people for problems they cannot fix.
Major section
Review Facets Surface to Platform
Interaction design: tasks, flows, controls, feedback, errors, confirmations, and recovery.
- Industrial design: form factor, materials, mounting, reach, durability, placement, and maintenance access.
- Interusability: consistency across device, app, dashboard, gateway, installer tool, and support tool.
- Conceptual model: the explanation users can hold about sensing, automation, data freshness, permissions, and override.
Deck summary
Key takeaways
In an IoT review, that idea is practical.
- The classic ubiquitous-computing scale of tabs, pads, and boards still helps review IoT products.
- Proximity might suppress a notification, change display behavior, or infer attention.
- Proximity sensors, touch-sensitive bezels or device sides, and accelerometers can make interaction more context-aware, but only when the product explains what those signals mean.
- The eight facets help a team review a connected product from what people see to what the platform must own.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team has a polished app and device shell for shared-room availability, but stale state and support diagnosis are unclear. Which 8-facet record is strong enough to accept the design?
Show answer
Answer: A An 8-facet record should connect visible UI, interaction, physical design, interusability, conceptual model, service workflow, product promise, platform responsibility, owners, and change conditions.
Print reference
Answers
Answer key.
- A · An 8-facet record should connect visible UI, interaction, physical design, interusability, conceptual model, service workflow, product promise, platform responsibility, owners, and change conditions.