UX Design · Study deck
IoT Prototyping: Questions and Learning Loops
A prototype should answer one risky question before the team builds more.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: If the question is whether installers recognize a failed pairing state, the team can stop when realistic installers encounter denied permission, weak signal, and offline reader states and can explain the next action.
- Explain: The later Fidelity Decision Map routes the artifact choice, the Decision-First Prototype Learning Loop governs iteration, and the Prototype Review Record preserves evidence, ownership, limits, and change conditions.
- Explain: A smooth phone mock-up can test the invite words, but it cannot show what happens when the reader is offline or the installer chooses the wrong account.
Major section
Start Simple
A housing team wants residents to share access to a new entry reader.
- A smooth phone mock-up can test the invite words, but it cannot show what happens when the reader is offline or the installer chooses the wrong account.
- If residents misunderstand the invite, paper screens and role-play may be enough.
- A useful review can stay brief.
Major section
Start Simple (continued)
If the concern is a weak signal at the door, use working hardware in the real entrance.
- If support handoff is the risk, include the resident, installer, and support worker in the same rehearsal.
- One prototype cannot prove every part of a connected product.
- A sketch can settle words and order.
- A working board can expose timing and power.
Major section
Start Simple (continued)
The deeper sections compare levels of detail, mixed physical and screen work, field pilots, and the review record that carries limits into the next decision.
- A role-play can expose a poor hand-off.
- A field form can expose reach and access.
- End with one clear decision: proceed, change the design, or build a more faithful test.
Major section
In 60 Seconds
IoT prototypes are learning tools.
- A strong prototype is not the most polished artifact the team can build.
- For connected products, prototype choices must cover more than a screen flow.
- They may need to test physical placement, sensor behavior, actuator safety, offline state, shared use, permissions, setup recovery, accessibility, power assumptions, update behavior, support handoff, and service operations.
Major section
In 60 Seconds (continued)
Storyboard or role-play when the uncertainty is context, handoff, timing, or service behavior around the device.
- Wizard of Oz when the uncertainty is whether users understand, trust, or want a smart behavior before the automation exists.
- Digital click-through when the uncertainty is navigation, visual hierarchy, feedback, or task flow.
- Breadboard or bench prototype when the uncertainty is sensing, actuation, connectivity, latency, or device feedback.
- The goal is to collect the next trustworthy piece of evidence.
Major section
Overview: Fidelity Follows the Risk
Prototype fidelity is not one scale from rough to finished.
- A paper flow can make wording and task order observable while leaving device timing untested.
- A bench rig can expose sensing, radio behavior, latency, and local feedback while leaving placement and support context unproven.
- A strong prototype plan also has a stop condition.
Major section
Overview: Fidelity Follows the Risk (continued)
A bounded field trial is appropriate when the blocked question genuinely requires ordinary context and the exposure can be controlled.
- The same product may need different prototype focuses in parallel, repeatedly, or in a dependency-driven order; they are not mandatory rungs.
- The later Fidelity Decision Map routes the artifact choice, the Decision-First Prototype Learning Loop governs iteration, and the Prototype Review Record preserves evidence, ownership, limits, and change conditions.
- If the question is whether installers recognize a failed pairing state, the team can stop when realistic installers encounter denied permission, weak signal, and offline reader states and can explain the next action.
Major section
Practitioner: Build the Right Slice
Prototype slices should be concrete enough for the risk.
- Digital flows can use Figma, HTML, or a small React/Vue prototype to test task sequence, ARIA names, focus order, consent timing, and notification copy.
- Measurement should match the claim.
- A support-board stub should show whether an installer or resident owns the next action.
Major section
Prototype Gaps Become Product Gaps
A click-through may show a successful unlock without command acknowledgement.
- A bench sensor may publish clean MQTT messages without enclosure interference.
- A pilot may look stable because firmware update, battery depletion, ownership transfer, and support escalation were outside scope.
- Under-the-hood prototype review asks which implementation details change the interaction.
Major section
Prototype Gaps Become Product Gaps (continued)
Failure coverage: include duplicate commands, low battery, expired credential, missing permission, lost connection, update rollback, and support handoff when those affect use.
- The review should also separate product risk from instrumentation risk.
- A packet capture can prove that an MQTT acknowledgement arrived, but it does not prove that the resident understood the pending state.
- This boundary discipline keeps prototype evidence portable.
Major section
Prototypes Answer Questions
Every useful prototype starts with one review question.
- Without that question, teams often build impressive artifacts that do not remove the actual risk.
- The stronger brief tells the team what to include, what to ignore, who to observe, and what evidence will change the design.
- A screen mockup is enough for wording and flow.
Deck summary
Key takeaways
A housing team wants residents to share access to a new entry reader.
- If the concern is a weak signal at the door, use working hardware in the real entrance.
- The deeper sections compare levels of detail, mixed physical and screen work, field pilots, and the review record that carries limits into the next decision.
- IoT prototypes are learning tools.
- Storyboard or role-play when the uncertainty is context, handoff, timing, or service behavior around the device.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team is reviewing a shared access-reader prototype that tests invite wording but not offline reader state or support handoff. Which prototype record is strong enough to make the decision reviewable?
Show answer
Answer: A A reviewable prototype decision ties the question, role, context, artifact, included signals, excluded risks, feedback, recovery, validation evidence, owner, and change condition together before the design is trusted.
Print reference
Answers
Answer key.
- A · A reviewable prototype decision ties the question, role, context, artifact, included signals, excluded risks, feedback, recovery, validation evidence, owner, and change condition together before the design is trusted.