Human-Centred IoT 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: If the risk is a missed alert, validation must include the event source, transmission, acknowledgement, and local feedback, with timestamps that distinguish delay from user hesitation.
- Explain: The ESP8266 and MQTT broker then expose connectivity and message-flow behaviour, while the LED or display and mobile app provide local and remote feedback.
- 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: A screen flow can test how people move through it, but cannot prove delay or a live link.
Major section
Fidelity Decision Map
A rough story can test meaning and order.
- A screen flow can test how people move through it, but cannot prove delay or a live link.
- A person can stand in for smart code when the question is about the user's response.
- Bench gear suits tests of sensing, action, power, or radio use.
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.
- The user gives an input and gets what looks like a smart reply.
- A hidden person sees that input, makes the choice the system cannot yet make, and starts the reply by hand.
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.
- That chain can validate interfaces and basic timing.
Major section
Medium-Fidelity Prototypes (continued)
The ESP8266 and MQTT broker then expose connectivity and message-flow behaviour, while the LED or display and mobile app provide local and remote feedback.
- For example, a real sensor may publish readings while the analytics, app state, support workflow, or recommendation logic is simulated.
- Hybrid prototypes are useful when the team needs realistic user behavior before every backend or hardware component is finished.
- They must be labeled carefully in the review record.
Major section
Prototype Review Record
The question may ask whether a first time installer can recover from pairing failure.
- Context records the user, space, device state, task, and handoff, while included signals show what was real enough to trust.
- Excluded risks name what the artifact did not test.
- Question: the uncertainty the prototype was built to answer.
- Artifact: what was actually built or simulated.
Major section
Prototype Review Record (continued)
That boundary matters when a smooth scripted recovery is later cited as proof of network reliability or field support readiness.
- 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
Pick Fidelity for the Maintenance Alert
For a maintenance alert button, first decide what uncertainty the next prototype must answer.
- A paper card can expose whether the label and handoff are understood.
- A clickable screen can test whether staff find the acknowledgement path.
- A device-and-gateway prototype is needed to measure whether the physical indicator and remote acknowledgement agree during a dropped link.
Major section
Match the Prototype to the Failure Mechanism
A screen simulation has no device timing, packet loss, or physical placement.
- If the risk is a missed alert, validation must include the event source, transmission, acknowledgement, and local feedback, with timestamps that distinguish delay from user hesitation.
- If the risk is comprehension, observation of the task can be decisive before hardware is ready.
- Fidelity is useful only relative to the claim being tested: a high-fidelity visual can still leave the system behaviour unrepresented.
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
A rough story can test meaning and order.
- 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.
- The ESP8266 and MQTT broker then expose connectivity and message-flow behaviour, while the LED or display and mobile app provide local and remote feedback.
Retrieval practice
Recall check 1 of 2
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.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A paper alert card tests whether staff understand an acknowledgement label. What claim can it support?
Show answer
Answer: A Paper can test meaning in the task, not hardware performance.
Q3A high fidelity app shows an alert clearing instantly. What prototype is needed to test link loss?
Show answer
Answer: B The failure claim needs the actual command and device path.
Print reference
Answers
Answer key.
- B · A prototype should be judged by the question it answers.
- A · Paper can test meaning in the task, not hardware performance.
- B · The failure claim needs the actual command and device path.