UX Design · Study deck

IoT Design Facets: Service and Platform

Each device surface looks usable alone, but the service crosses screens, people, support records, and hidden platform state.

UX Uma is your guide for this deck.

design-facetsiot-uxinterusability
UX Uma, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain: Interusability problems often appear as user confusion: "The device says one thing, but the app says another." That is a design issue, not only a synchronization issue.
  • Explain: The wall display, mobile app, operator dashboard, installer tool, and support console should use the same state vocabulary for occupied, available, reserved, stale, offline, and manual override.
  • Explain: MQTT retained state, device-shadow reported state, last-seen timestamps, room assignment, gateway id, and support correlation id should explain why one surface shows a different state.
  • Explain: A shared-room availability product needs interusability and conceptual-model review.
iotclass.org

Major section

Interusability

Interusability is the experience of moving across connected surfaces.

  • A device, phone, web dashboard, gateway, voice interface, installer screen, and support tool should feel like one coherent system where relevant.
  • Interusability problems often appear as user confusion: "The device says one thing, but the app says another." That is a design issue, not only a synchronization issue.
Four device outlines -- TV, tablet, phone, and laptop -- each show the same status icon, label bars, and progress marker, connected by a dashed sync line to show a shared session state instead of four separate ones.
Four device outlines -- TV, tablet, phone, and laptop -- each show the same status icon, label bars, and progress marker, connected by a dashed sync line to show a shared session state instead of four separate ones.
iotclass.org

Major section

Productization

Productization connects the design to a market, audience, promise, and operating model.

  • In this review process, product claims should stay evidence-bound and avoid unsupported numbers.
  • If the product promise depends on platform behavior, service support, or data quality, those dependencies must be visible in the design record.
A three-step productization pipeline from value proposition to conceptual model to interaction model, paired with a 2x2 matrix of existing-market and new-market cells naming low-cost product, niche product, new type of product, and new product.
A three-step productization pipeline from value proposition to conceptual model to interaction model, paired with a 2x2 matrix of existing-market and new-market cells naming low-cost product, niche product, new type of product, and new product.
iotclass.org

Major section

Facet Review Record

Facet: which design facet is affected.

  • User role: owner, shared user, installer, operator, maintainer, or support.
  • Evidence: observation, test, pilot, support record, technical validation, or design review.
  • Decision: what will be kept, changed, removed, simplified, or checked again.
  • Hidden dependency: service, platform, data, update, permission, or support dependency.
IoT facet review record: ten fields to preserve for each design-facet decision.
IoT facet review record: ten fields to preserve for each design-facet decision.
iotclass.org

Major section

Calm Technology Attention Policy

Calm technology is not minimal UI.

  • Peripheral first: routine state should be available at a glance, through ambient cues, summaries, or predictable placement.
  • Interrupt only for action: alerts should interrupt only when the user can or must do something now.
  • Informs without overburdening — state is available, not forced into view.
Calm technology review map connecting user context, attention policy, system state, notification behavior, service ownership, and platform evidence.
Calm technology review map connecting user context, attention policy, system state, notification behavior, service ownership, and platform evidence.
iotclass.org

Major section

Worked Review: Shared Room Device

A team designs a device that shows whether a shared room is available.

  • The prototype includes a wall device, phone app, and operator dashboard.
  • Facet findings: UI uses "available" while the dashboard says "empty" and the device says "clear.".
  • Conceptual model does not explain confidence or freshness.
iotclass.org

Major section

Worked Review: Shared Room Device (continued)

Interaction design lets users reserve the room in the app, but the wall device does not show who owns the reservation.

  • Industrial design places the indicator where it is hard to see during hallway traffic.
  • Interusability fails when the wall display is current but the phone app shows an older state.
  • Service design does not cover room reassignment or device relocation.
  • Productization promises "room availability" but the evidence only supports recent motion.
iotclass.org

Major section

Worked Review: Maintenance Device

A maintenance sensor monitors a replaceable part and reports status to a building operator.

  • The team focuses on a clean dashboard but has not reviewed installation, replacement, or ownership transfer.
  • Facet findings: UI is clear for normal state but vague during sensor failure.
  • Industrial design makes the battery hard to reach after mounting.
iotclass.org

Major section

Common Findings

The device, app, and dashboard use different labels for the same state.

  • Automation is presented as certainty even when the evidence is inferred or stale.
  • Product claims are broader than the evidence.
  • Ownership transfer, reset, update failure, and decommissioning are missing.
  • Risk checks happen after the design is already framed as complete.
iotclass.org

Major section

Incremental Examples

A beginner review can start with a simple leak sensor that has one LED, one mobile card, and one push notification.

  • UI review checks whether "dry," "wet," "offline," and "battery low" are readable and not color-only.
  • Industrial design checks placement near a pipe, battery-door reach, reset access, and whether water exposure is obvious.
  • This pass does not yet prove support workflow, cloud outage behavior, or lifecycle ownership.
iotclass.org

Major section

Incremental Examples (continued)

A shared-room availability product needs interusability and conceptual-model review.

  • The wall display, mobile app, operator dashboard, installer tool, and support console should use the same state vocabulary for occupied, available, reserved, stale, offline, and manual override.
  • MQTT retained state, device-shadow reported state, last-seen timestamps, room assignment, gateway id, and support correlation id should explain why one surface shows a different state.
  • If the system only observes motion, the product promise should say "availability estimate" until door, reservation, or manual-confirmation evidence supports a stronger claim.
  • A campus deployment needs service, productization, and platform evidence before the visible design can be accepted.
iotclass.org

Deck summary

Key takeaways

Interusability is the experience of moving across connected surfaces.

  • Productization connects the design to a market, audience, promise, and operating model.
  • Facet: which design facet is affected.
  • Calm technology is not minimal UI.
  • A team designs a device that shows whether a shared room is available.
iotclass.org

Retrieval practice

Recall check

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

Q1A connected product has a polished app and attractive device shell, but support cannot diagnose setup failures, ownership transfer is unclear, and offline behavior contradicts the product promise. What is the strongest 8-facet review response?

AApprove the design because the visible UI and industrial design are complete
BHold until service, product, and platform evidence have owners and recovery behavior
CRemove the app and rely only on the device shell
DAdd more visual indicators so users can see that something went wrong
Show answer

Answer: B The 8 facets broaden review beyond visible UI.

iotclass.org

Print reference

Answers

Answer key.

  1. B · The 8 facets broaden review beyond visible UI.
iotclass.org