Human-Centred IoT Design · Study deck
Prototype Testing: Test Planning
A small study can expose problems but cannot measure every user's success rate.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The: Firmware row adds race conditions, flash wear, and safe OTA rollback around the bootloader; these can turn an apparently simple setup task into a delayed or failed state.
- Explain: If the question is whether residents can recover when the access reader is offline, the test must include reader status, app language, local feedback, and support routing.
- Explain: Reading the stack with participant behavior lets the team distinguish confusing copy from a transport delay or device fault and record the right design response.
- Explain: The goal is to reduce uncertainty before the design becomes expensive to change.
Major section
Start Simple
They say the design looks simple, then miss the stale-state warning and leave believing the door is secure.
- A polite opinion did not reveal what the person understood or did during the task.
- Recruit people who match the role, setting, ability, and responsibility.
- A small study can expose problems but cannot measure every user's success rate.
Major section
In 60 Seconds
The goal is to reduce uncertainty before the design becomes expensive to change.
- User testing shows what people actually do with an IoT prototype.
- IoT testing must include the physical device, the interface, the environment, and the service promise.
- The goal is not to collect compliments.
Major section
Overview: Test the Real Use Path
If the question is whether residents can invite a visitor, the test can be screen-heavy.
- IoT user testing is strongest when it observes the whole path a person must use, not only the screen.
- The test should include the role, place, device state, service dependency, support handoff, and recovery path that make the task realistic.
- The: Network row then names BLE, Wi-Fi, LoRa: MQTT, CoAP and tests packet loss, jitter, interoperability, and back-pressure.
Major section
Overview: Test the Real Use Path (continued)
A first lab test may ask a resident to create a visitor invite in a clickable prototype.
- A participant who can complete a clean app walkthrough may still fail when a reader is offline, a sensor value is stale, a permission is missing, or a physical indicator is hard to see.
- For a shared access product, the same task can mean different tests.
- A test can stay small when the question is wording or findability.
Major section
Overview: Test the Real Use Path (continued)
If the question is whether residents can recover when the access reader is offline, the test must include reader status, app language, local feedback, and support routing.
- The: Firmware row adds race conditions, flash wear, and safe OTA rollback around the bootloader; these can turn an apparently simple setup task into a delayed or failed state.
- Reading the stack with participant behavior lets the team distinguish confusing copy from a transport delay or device fault and record the right design response.
- The useful unit of planning is therefore a test risk, not a page in the interface.
Major section
Instrument Tests Without Leading
Testing needs observation and system evidence.
- In a device prototype, capture LED or haptic feedback, BLE pairing state, Wi-Fi provisioning state, command acknowledgement, battery state, and support handoff.
- Concrete tools depend on the artifact.
- Each row should name the task, participant role, seeded state, simulated part, expected observable behavior, system signal, and decision owner.
Major section
Findings Need State Causes
A user-test finding is weak if the team cannot explain which system state produced the behavior.
- The design response should match the cause.
- These signals keep the team from treating all confusion as a wording problem.
- Good tests also make failure states repeatable.
- Cause: tie the finding to state, timing, permission, feedback, physical context, or support ownership.
Major section
Turn Tests into Evidence
Strong testing watches whether people can use the design in the context where it must work.
- The behavior task reveals whether the user understands device state, recovery language, support route, and confidence boundary.
- It also reveals whether the prototype includes the right failure state.
- If the test includes only the happy path, the finding is incomplete.
Major section
User Test Evidence Loop
Prepare a resident role and a seeded offline reader after a battery change, then ask the person to show what they would do next.
- Observe before coaching so the test can expose whether the status and recovery route are clear.
- This makes it possible to see whether a clearer message actually helps the resident recover.
Deck summary
Key takeaways
They say the design looks simple, then miss the stale-state warning and leave believing the door is secure.
- The goal is to reduce uncertainty before the design becomes expensive to change.
- If the question is whether residents can invite a visitor, the test can be screen-heavy.
- A first lab test may ask a resident to create a visitor invite in a clickable prototype.
- If the question is whether residents can recover when the access reader is offline, the test must include reader status, app language, local feedback, and support routing.
Retrieval practice
Recall check 1 of 4
UX Uma says: answer from memory, then check your reasoning.
Q1A resident says a lock app looks simple but misses its stale-state warning during a task. What finding should guide the next test?
Show answer
Answer: C Record the missed warning and device state, then test whether revised feedback changes task behavior.
Retrieval practice
Recall check 2 of 4
UX Uma says: answer from memory, then check your reasoning.
Q2A team is testing a shared access setup prototype that includes expired invites, wrong-unit selection, offline reader state, and support handoff. Which test record makes the finding reviewable?
Show answer
Answer: C A reviewable IoT user-test finding ties participant fit, task goal, prototype state, observed behavior, failure state, evidence, decision, owner, open issue, and change condition together before the design changes.
Retrieval practice
Recall check 3 of 4
UX Uma says: answer from memory, then check your reasoning.
Q3A clickable reader flow now works in a quiet lab, but doorway lighting and weak site Wi-Fi may change setup. What is the next evidence gate?
Show answer
Answer: C Run a bounded field test of the real doorway and network conditions before a release claim.
Retrieval practice
Recall check 4 of 4
UX Uma says: answer from memory, then check your reasoning.
Q4A shared door reader fails during visitor handoff. Who should take part in the next bounded usability test?
Show answer
Answer: C Residents, visitors, and support or installers whose roles match the handoff risk.
Print reference
Answers
Answer key.
- C · Record the missed warning and device state, then test whether revised feedback changes task behavior.
- C · A reviewable IoT user-test finding ties participant fit, task goal, prototype state, observed behavior, failure state, evidence, decision, owner, open issue, and change condition together before the design changes.
- C · Run a bounded field test of the real doorway and network conditions before a release claim.
- C · Residents, visitors, and support or installers whose roles match the handoff risk.