UX Design · Study deck
IoT Prototyping: Fidelity and Validation Methods
A paper control can test a task flow, while a live radio mock-up can test delay.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Bench prototypes use development boards, sensors, actuators, debug wiring, test fixtures, and simple firmware to prove a technical behavior before form factor or production design.
- Explain: The important decision is not "did the prototype work?" The important decision is which uncertainty was reduced and which risk moves to the next prototype.
- Explain: Quality depends on matching the artifact to the question, labeling simulated parts, testing failure and recovery when relevant, and recording what remains unproven.
- Explain: Participants should be debriefed when the session is complete, and the prototype record should clearly state what was simulated.
Major section
Low-Fidelity Prototypes
For IoT, sketches should include device state, not only app screens.
- Paper is useful because the facilitator can change the flow immediately when a device state or support step is missing.
- Physical mockups test reach, placement, size, affordance, visibility, mounting, and shared use.
- Service rehearsals let the team act out installation, failure, escalation, replacement, and support handoff.
Major section
Simulated Smart Behavior
Wizard of Oz prototypes test a smart behavior before the smart system is built.
- A human operator quietly simulates automation so the team can observe whether users understand, trust, override, or reject the behavior.
- Participants should be debriefed when the session is complete, and the prototype record should clearly state what was simulated.
Major section
Medium-Fidelity Prototypes
They should still be question-driven.
- Digital click-through prototypes are useful for mobile apps, dashboards, setup flows, consent screens, notification controls, and support journeys.
- Bench prototypes use development boards, sensors, actuators, debug wiring, test fixtures, and simple firmware to prove a technical behavior before form factor or production design.
- They must be labeled carefully in the review record.
Major section
Medium-Fidelity Prototypes (continued)
Otherwise, stakeholders may believe a mocked subsystem has already been validated.
- The record should separate what the bench prototype proves from what remains unproven.
- A bench prototype may prove that the sensor can read a value.
- For example, a real sensor may publish readings while the analytics, app state, support workflow, or recommendation logic is simulated.
Major section
Prototype Review Record
Question: the uncertainty the prototype was built to answer.
- Artifact: what was actually built or simulated.
- Included signals: the parts of the system that were real enough to trust.
- Excluded risks: what the prototype did not test.
- Evidence: observed behavior, failures, quotes, logs, or support findings.
Major section
Laundry Sensor Review
A team wants to prototype a sensor that reports whether shared laundry machines are available.
- The first uncertainty is not the sensor.
- Pilot:: Observe real usage, false readings, support contacts, and maintenance work over a bounded period.
- The important decision is not "did the prototype work?" The important decision is which uncertainty was reduced and which risk moves to the next prototype.
Major section
Worked Review: Maintenance Alert Button
A maintenance alert button in a shared facility seems simple until the team tests real use.
- A digital prototype alone cannot answer the placement, confirmation, offline, and operational questions.
- A bench prototype alone cannot answer whether users understand the service promise.
- The right plan uses multiple small prototypes, each with a clear evidence target.
Major section
Common Prototyping Defects
A polished demo can impress stakeholders while avoiding the hard question.
- If the prototype does not name the uncertainty, it should not be accepted as evidence.
- IoT products must explain offline state, stale data, failed setup, rejected commands, permission problems, low power, and safe fallback.
- Prototypes that skip those states create false confidence.
Major section
Common Prototyping Defects (continued)
Mocked analytics, fake sensor data, manual support handling, and hidden operator control are legitimate prototype techniques.
- They become dangerous when the record does not say what was simulated.
- Higher fidelity can slow learning by making the team reluctant to change direction.
- Physical context must be prototyped when it affects use.
- Connected products are operated after they are designed.
Major section
Summary
IoT prototyping is evidence work.
- The best prototype is the lightest artifact that can answer the current uncertainty without hiding the risks that matter.
- Paper, cardboard, storyboards, Wizard of Oz tests, digital click-throughs, bench rigs, integrated form prototypes, and pilots all have a place.
- Quality depends on matching the artifact to the question, labeling simulated parts, testing failure and recovery when relevant, and recording what remains unproven.
Major section
Concept Relationships
Interactive Design Process frames the loop that decides which question needs a prototype.
- Interactive Design Principles defines the qualities that prototypes should make observable.
- User Testing and Iteration explains how to observe prototype use and convert evidence into revisions.
- Prototype fidelity also connects to engineering review.
Deck summary
Key takeaways
For IoT, sketches should include device state, not only app screens.
- Wizard of Oz prototypes test a smart behavior before the smart system is built.
- They should still be question-driven.
- Otherwise, stakeholders may believe a mocked subsystem has already been validated.
- Question: the uncertainty the prototype was built to answer.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team has a polished app prototype for a shared access reader. It tests invitation wording and button order, but it does not include reader offline state, expired invites, failed pairing, installer recovery, or support handoff. What is the strongest review finding?
Show answer
Answer: B A prototype should be judged by the question it answers.
Print reference
Answers
Answer key.
- B · A prototype should be judged by the question it answers.