Human-Centred IoT Design · Study deck

IoT Interaction Design: Discovery Through Release

An IoT interface starts with the user's setting and constraint.

UX Uma is your guide for this deck.

interactive-design-process-mapdesign-thinkingiot-prototyping

After studying this chapter

Learning objectives

You will be able to:

Explain: Scenario: a shared building product lets residents unlock a door with a phone, but setup failures are common when an invite expires, the wrong unit is selected, or the reader is temporarily offline.
Explain: Connected products often have more than one possible interaction path: physical control, app flow, spoken prompt, local indicator, printed setup code, support workflow, automation rule, or maintenance tool.
Explain: A test may rule an idea out or make the need more clear, so the route can open again rather than push a weak idea toward launch.

Major section

Process Map

A team can move forward only when the current stage has produced evidence strong enough for the next decision.

Operator evidence says alerts arrive too often and that urgent, assigned, snoozed, repeated, and resolved states are hard to distinguish.
That becomes a learning question about making an alert actionable without adding fatigue.
The team then chooses a prototype and tests it against a realistic task, rather than polishing a screen before the question is clear.

Six-phase interactive design loop illustrated through a pump-monitor maintenance alert: context evidence leads to a revised prototype with explicit alert state, then realistic testing determines the next iteration or release decision.

Major section

Ideate Alternatives

Ideation deliberately separates idea generation from selection.

Connected products often have more than one possible interaction path: physical control, app flow, spoken prompt, local indicator, printed setup code, support workflow, automation rule, or maintenance tool.
The point is not to generate novelty for its own sake.
The point is to avoid false certainty.

Ideation process from a problem statement through diverse idea generation, selection, evaluation, and tested prototypes.

Major section

Ideate Alternatives (continued)

They keep new ideas tied to a real result.

The first tool that seems to fit is not yet the answer.
The next step tests each idea against risk, cost to build, privacy, and facts already found.
A test may rule an idea out or make the need more clear, so the route can open again rather than push a weak idea toward launch.

Major section

Divergent and Convergent Work

The centre is not a one-way gate: a prototype may expose a mistaken problem definition and send the team back.

The model helps only when each convergence states what evidence justified discarding the alternatives.
observing different users and contexts. Generating alternative interaction paths. Exploring physical, mobile, voice, support, and automation surfaces. Trying low-cost prototypes that answer different questions.
selecting the problem frame. Choosing the simplest useful prototype. Deciding which evidence matters. Accepting, rejecting, or revising a design path. Recording owners and change conditions.

Double Diamond design framework showing divergent discovery, convergent definition, divergent development, and convergent delivery.

Major section

Incremental Examples

Scenario: a shared building product lets residents unlock a door with a phone, but setup failures are common when an invite expires, the wrong unit is selected, or the reader is temporarily offline.

The review should reject a process that jumps directly to app screens without testing device feedback, offline behavior, role boundaries, or support evidence.
Scenario: a pump monitor sends maintenance alerts.
Scenario: an industrial gateway receives an over-the-air firmware update.

Major section

Incremental Examples (continued)

The review should reject a process that treats the update as a single success message.

Operators complain that alerts arrive too often and do not explain whether action is urgent, assigned, snoozed, repeated, or resolved.
The review should reject a process that only changes colors or notification wording without checking alert ownership, state, repetition, recovery, and escalation.
The design path is not ready until users and support staff can see the same update state and recovery boundary.

Major section

Process Record

This prevents a past test from silently becoming permanent proof.

The design question names the outcome and boundary, while alternatives show which routes were considered.
The decision can be to iterate, stop, or release; it should not stand alone without that trace.
Owner, open issue, accepted tradeoff, and change condition keep the decision reviewable as the product or context changes.

Major section

Micro-Exercise: Choose the Loop Point

For each situation, write which stage should happen next: discover, define, ideate, prototype, test, iterate, or release.

A smart-lock team knows setup fails when the reader is offline, but no one has observed whether residents understand the offline message.
A pump-monitoring team has three alert concepts, but has not compared local indicator, mobile notification, dashboard queue, and maintenance-ticket paths.
A gateway-update flow works in the happy path, but support cannot see firmware version, rollback state, or command correlation id.

Try it: Micro-Exercise: Choose the Loop Point in the chapter

Deck summary

Key takeaways

A team can move forward only when the current stage has produced evidence strong enough for the next decision.

Ideation deliberately separates idea generation from selection.
They keep new ideas tied to a real result.
The centre is not a one-way gate: a prototype may expose a mistaken problem definition and send the team back.
Scenario: a shared building product lets residents unlock a door with a phone, but setup failures are common when an invite expires, the wrong unit is selected, or the reader is temporarily offline.

Retrieval practice

Recall check 1 of 3

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

Q1A team prototypes a polished mobile setup flow for a shared door reader, but testing never includes expired invites, wrong-unit selection, reader offline state, installer recovery, or support handoff. What is the strongest process critique?

AThe prototype should be more visually polished before testing again.

BThe process skipped realistic failure and recovery evidence

CThe team should ship because the happy path works in the app.

DThe team should abandon user testing and rely on support tickets after launch.

Show answer

Answer: B The process is weak when it tests only the happy path.

Retrieval practice

Recall check 2 of 3

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

Q2A visitor invite prototype looks polished but residents cannot tell whether an invite arrived. What is the next loop?

APolish the final invitation states and hand the prototype to development.

BAsk residents to rate the invite wording before measuring whether delivery is understood.

CRevise invite feedback and retest the handoff with new residents.

Show answer

Answer: C The next iteration targets the observed failed handoff.

Retrieval practice

Recall check 3 of 3

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

Q3Which artifact makes a design loop decision auditable after a failed reader trial?

AA record linking the observed failure, change, retest, and decision owner.

BA version history linking each prototype screen to the team’s design rationale.

CA backlog item recording the reader failure, proposed change, and assigned owner.

Show answer

Answer: A The chain lets the team explain why the design changed.

Print reference

Answers

Answer key.

B · The process is weak when it tests only the happy path.
C · The next iteration targets the observed failed handoff.
A · The chain lets the team explain why the design changed.