Connected Product and Service 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: The middle fields ask how that choice affects the user and the rest of the service, so a screen change is not reviewed in isolation from installation or support.
  • 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: Interusability is the experience of moving across connected surfaces.
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

The middle fields ask how that choice affects the user and the rest of the service, so a screen change is not reviewed in isolation from installation or support.

  • The last fields keep the owner and next check visible.
  • Facet: which design facet is affected.
  • User role: owner, shared user, installer, operator, maintainer, or support.
IoT facet review record with ten fields: facet, user role, evidence, decision, user impact, hidden dependency, risk, owner, accepted tradeoff, and change condition.
IoT facet review record: ten fields to preserve for each design-facet decision.
iotclass.org

Major section

Facet Review Record (continued)

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.
  • Risk: privacy, safety, accessibility, security, support, maintenance, reliability, or lifecycle risk.
  • Accepted tradeoff: known limit and reason it is acceptable.
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.
  • One owner must handle delay, repeats, and loss.
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.
  • The middle fields ask how that choice affects the user and the rest of the service, so a screen change is not reviewed in isolation from installation or support.
  • Evidence: observation, test, pilot, support record, technical validation, or design review.
  • Calm technology is not minimal UI.
iotclass.org

Retrieval practice

Recall check 1 of 2

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

Q1A building sensor sees routine changes all afternoon. When should the product interrupt the caretaker?

AAlert on every routine change even when caretaker has no action.
BInterrupt only for action now; present routine status quietly.
CNever alert even when immediate caretaker action is needed.
DDisplay every raw sensor value as an urgent alarm.
Show answer

Answer: B When a change needs the caretaker to act now; keep routine state in a quiet view.

iotclass.org

Retrieval practice

Recall check 2 of 2

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

Q2A 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 polished visuals because a clear interface also establishes service and support recovery.
BRemove the app and rely on the device shell for all support.
CHold until service, product, and platform evidence has owners and recovery.
DAdd visual indicators without fixing diagnosis or ownership.
Show answer

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

iotclass.org

Print reference

Answers

Answer key.

  1. B · When a change needs the caretaker to act now; keep routine state in a quiet view.
  2. C · The 8 facets broaden review beyond visible UI.
iotclass.org