8 IoT Design Facets: Service and Platform

8.1 Start With the Situation

This section: Start With the Situation — Each device surface looks usable alone, but the service crosses screens, people, support records, and hidden platform state.

Each device surface looks usable alone, but the service crosses screens, people, support records, and hidden platform state. The team must test whether those parts agree and whether attention escalates only when action is needed.

8.2 Overview

This section: Overview — This route connects cross-device use to conceptual, service, product, platform, and calm-technology decisions.

This route connects cross-device use to conceptual, service, product, platform, and calm-technology decisions.

This is part 2 of 2. Review IoT Design Facets: Surfaces and Interaction when you need the first route.

8.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• evaluate interusability across surfaces
• test conceptual, service, and platform responsibilities
• apply a calm attention policy

8.4 Interusability

This section: Interusability — Interusability is the experience of moving across connected surfaces.

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.

Review:

whether the same state has the same name across surfaces. whether changes made on one surface appear on other surfaces clearly enough. whether permissions, ownership, and shared access are understandable. whether each surface has a clear role instead of duplicating everything. whether support can explain what happened without exposing unnecessary private data. whether handoff between user, installer, operator, and support is documented.

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.

Use Figure 8.1 to ask whether one session remains understandable across device surfaces.

+

The TV offers room scale display, the tablet supports review, the phone gives a quick glance, and the laptop has space for detail. Those surfaces are useful only if status, position, and identity still refer to the same session as the person moves between them. The figure places synced session state above the devices to make that dependency visible. For this facet, review what each surface can show and how a person can tell that the state has followed them.

8.5 Conceptual Model

This section: Conceptual Model — The conceptual model is the product’s explanation of itself.

The conceptual model is the product’s explanation of itself. Users need a reliable way to understand what the system senses, what it infers, what it controls, and when they can intervene.

Review:

• whether the model separates measured state from inferred state
• whether automation is explained in user terms
• whether users can predict likely system behavior
• whether stale, missing, or uncertain data is shown honestly
• whether the model covers shared users, permissions, and ownership
• whether support and documentation use the same explanation as the interface

Weak model: “The device is smart.” Stronger model: “The device estimates room use from recent motion and door events; the estimate may be stale when the link is weak; users can override the status locally.”

8.6 Service Design

This section: Service Design — Service design covers the journey around the product.

Service design covers the journey around the product. For IoT, the service often determines whether the device remains useful after the first setup.

Review:

how users choose, install, pair, and authorize the device. what happens when the product changes owner or location. how maintenance is scheduled, explained, and confirmed. how support diagnoses device, account, permission, connectivity, and update issues. how users recover from lost access or failed setup. how replacement, reuse, transfer, and decommissioning are handled.

Service design should be reviewed before launch, not after support tickets reveal missing flows.

8.7 Productization

This section: Productization — Productization connects the design to a market, audience, promise, and operating model.

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.

Review:

who the product is for. what problem it promises to solve. what use cases are out of scope. what operating burden the user or organization accepts. what privacy, safety, accessibility, and maintenance assumptions shape the promise. what evidence supports the claim. what tradeoff was accepted and who approved it.

If the product promise depends on platform behavior, service support, or data quality, those dependencies must be visible in the design record.

The path in Figure 8.2 connects a product promise to the way people encounter it.

+

A value proposition states the benefit; the conceptual model is how a user pictures that benefit; the interaction model is what they do each day to obtain it. The figure then crosses market familiarity with how different the offer is, producing low cost, niche, new type, and new product positions. These are separate checks. A strong price position cannot repair an unclear interaction, and a clear interface cannot prove demand for a new market. Keep the promise, model, and proposed position aligned in the review.

8.8 Platform Design

This section: Platform Design — Platform design is hidden but decisive.

Platform design is hidden but decisive. It includes identity, local behavior, cloud dependency, permissions, telemetry, updates, observability, integrations, security controls, and recovery.

Review:

what works locally and what requires a remote service. who owns device identity, user identity, group access, and reset. what data is collected and why. how updates are staged, verified, explained, and recoverable. what telemetry support needs and what should not be exposed. what happens during weak connectivity, expired credentials, low battery, unavailable cloud, failed update, or stale data. whether platform constraints contradict the product promise.

Platform design should be reviewed as a UX dependency. A platform failure that leaves users confused is still a user experience failure.

8.9 Facet Review Record

This section: Facet Review Record — Use Figure 8.3 to preserve the reason for each design facet decision.

Use Figure 8.3 to preserve the reason for each design facet decision.

+

The first fields name the facet, user role, evidence source, and decision. 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. Read across the record before accepting a change: if the affected role or evidence is missing, the team cannot tell whether the choice solves the stated problem or merely moves it to another touchpoint.

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. User impact: what the user sees, does, trusts, or recovers from. Hidden dependency: service, platform, data, update, permission, or support dependency. Risk: privacy, safety, accessibility, security, support, maintenance, reliability, or lifecycle risk. Owner: team or role accountable for the decision. Accepted tradeoff: known limit and reason it is acceptable. Change condition: context, role, platform, service, or product-promise change that reopens the decision.

Use Figure 8.4 to test whether context, system state, and ownership justify the attention level chosen for each product notification.

+

Read Figure 8.4 from user context and system state to the attention rule. These facts decide whether a cue stays at the edge of notice, grows more clear, or stops the user. The cue then crosses product, service, and platform lines. One owner must handle delay, repeats, and loss. The evidence path checks how easy the cue is to notice, when it arrives, who can use it, and how it recovers. A new context rule, risk level, device form, service route, or platform rule reopens the review. The same fact can feel calm on one surface and harsh on another.

8.10 Worked Review: Shared Room Device

This section: Worked Review: Shared Room Device — A team designs a device that shows whether a shared room is available.

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.”. 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. Conceptual model does not explain confidence or freshness. Service design does not cover room reassignment or device relocation. Productization promises “room availability” but the evidence only supports recent motion. Platform design depends on cloud state for ordinary use without a local fallback.

Revision direction

Standardize state labels. Distinguish measured motion, inferred availability, and freshness. Move ordinary status to the wall device and reserve app notifications for actions. Add support evidence for sensor placement, stale state, and connectivity. Record the product promise as “availability estimate” until stronger evidence supports a broader claim.

8.11 Worked Review: Maintenance Device

This section: Worked Review: Maintenance Device — A maintenance sensor monitors a replaceable part and reports status to a building operator.

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. Interaction design lacks a confirmation flow after replacement. Industrial design makes the battery hard to reach after mounting. Interusability differs between operator dashboard and installer tool. Conceptual model does not explain whether status is measured, inferred, or manually scheduled. Service design misses replacement confirmation and failed-maintenance escalation. Productization promises reduced manual checks without evidence of maintenance workflow fit. Platform design lacks clear owner for device reset and update failure.

Revision direction

Add replacement confirmation and stale-state language. Test physical access with the mounted device. Align dashboard and installer labels. Record who owns reset, maintenance confirmation, and support escalation. Review again when the device form, operator workflow, or platform update process changes.

8.12 Common Findings

This section: Common Findings — The team polishes UI while ignoring service and platform dependencies.

The team polishes UI while ignoring service and platform dependencies. 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. The physical product hides important sensing, privacy, power, or maintenance constraints. Product claims are broader than the evidence. Support cannot diagnose what the user experienced. Ownership transfer, reset, update failure, and decommissioning are missing. Risk checks happen after the design is already framed as complete.

8.13 Review Checklist

This section: Review Checklist — visible state, controls, and physical affordances fit the real context.

Use this checklist before accepting an 8-facet design record:

visible state, controls, and physical affordances fit the real context. user tasks, errors, confirmations, overrides, and recovery are represented. device, app, dashboard, installer, and support surfaces use consistent labels. the conceptual model explains sensing, inference, freshness, permissions, and automation. service workflows cover setup, maintenance, support, transfer, and decommissioning. product promise is evidence-bound and includes non-goals. platform dependencies and local fallback behavior are explicit. privacy, safety, accessibility, support, security, and lifecycle risks are reviewed. owner, accepted tradeoff, open issue, and change condition are recorded.

8.14 Incremental Examples

This section: Incremental Examples

8.15 Try It Now

This section: Try It Now

Choose an IoT product you know and write a one-row facet review:

8.16 Micro-Exercise: Find the Facet

This section: Micro-Exercise: Find the Facet — The app says “available” while the wall device says “clear.”.

For each symptom, identify the facet most likely to need review:

The app says “available” while the wall device says “clear.”. The support team cannot tell whether setup failed at Bluetooth pairing, account assignment, or Wi-Fi provisioning. A product page promises real-time room availability, but the only sensor is a motion detector with a stale last-seen timestamp.

8.17 Concept Check: Eight-Facet Approval

This section: Concept Check: Eight-Facet Approval

8.18 Concept Check: Match Facets to Evidence

This section: Concept Check: Match Facets to Evidence

8.19 Concept Check: Order the Facet Review

This section: Concept Check: Order the Facet Review

8.20 Summary

This section: Summary — The 8 facets of IoT design keep review work broad enough to catch problems that a screen-only or hardware-only review misses.

The 8 facets of IoT design keep review work broad enough to catch problems that a screen-only or hardware-only review misses. UI, interaction, and industrial design shape first use, while interusability, conceptual model, service design, productization, and platform design determine whether the product remains understandable and supportable.

Use the facet record to make each decision traceable to evidence. The review should preserve user role, evidence, decision, user impact, hidden dependency, risk, owner, accepted tradeoff, and change condition.

8.21 Key Takeaway

This section: Key Takeaway — IoT design facets should be reviewed together because attention, context, autonomy, feedback, privacy, and maintenance trade off in use.

IoT design facets should be reviewed together because attention, context, autonomy, feedback, privacy, and maintenance trade off in use.

8.22 See Also

This section: See Also — Calm Technology Attention Policy applies attention policy and calm behavior across the facet stack.

Calm Technology Attention Policy applies attention policy and calm behavior across the facet stack. Design Thinking for IoT supplies the field evidence and testing cycles that validate facet decisions. IoT Architecture Model Selection helps align platform responsibilities with architecture boundaries. IoT Design Patterns and Components provides implementation options after the facet risks and responsibilities are known. Understanding People and Context supplies the user context needed to review service and conceptual-model decisions.

8.23 What’s Next

This section: What’s Next — Continue to Design Model for IoT to review how architecture, facets, design thinking, and implementation patterns fit together across the design-model chapter series.

Continue to Design Model for IoT to review how architecture, facets, design thinking, and implementation patterns fit together across the design-model chapter series.