UX 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: 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.
- Explain: A stronger recovery test may seed an expired invite, put the reader into an offline state, and watch whether the participant understands the app copy, reader indicator, and support handoff.
- 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.
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
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.
- If the question is whether residents can invite a visitor, the test can be screen-heavy.
Major section
Overview: Test the Real Use Path (continued)
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.
- 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.
- For a shared access product, the same task can mean different tests.
Major section
Overview: Test the Real Use Path (continued)
The: Network row then names BLE, Wi-Fi, LoRa,: MQTT, CoAP and tests packet loss, jitter, interoperability, and back-pressure.
- 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.
- A first lab test may ask a resident to create a visitor invite in a clickable prototype.
- A test can stay small when the question is wording or findability.
Major section
Overview: Test the Real Use Path (continued)
A stronger recovery test may seed an expired invite, put the reader into an offline state, and watch whether the participant understands the app copy, reader indicator, and support handoff.
- A later field test may check whether poor lighting, weak Wi-Fi, quiet hours, phone battery, shared accounts, or delayed push notifications change the result.
- The useful unit of planning is therefore a test risk, not a page in the interface.
- It must become more realistic when the question depends on timing, physical placement, stale data, permission boundaries, support ownership, or confidence in a field setting.
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.
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.
- IoT user testing is strongest when it observes the whole path a person must use, not only the screen.
- 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.
- The: Network row then names BLE, Wi-Fi, LoRa,: MQTT, CoAP and tests packet loss, jitter, interoperability, and back-pressure.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A 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: A 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.
Print reference
Answers
Answer key.
- A · 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.