UX Design · Study deck
Prototype Testing: Neutral Tasks
The stronger task lets the user choose a path.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Test write neutral tasks with a concrete scenario and pass criteria.
- Validate concept check: order the user test with a concrete scenario and pass criteria.
- test write neutral tasks with a concrete scenario and pass criteria
- 'validate concept check: order the user test with a concrete scenario and pass criteria'
Major section
Write Neutral Tasks
hands full during entry. Weak network during setup. Device shared by several people. App permission denied. Sensor reading delayed or stale. Physical indicator hard to see. Support handoff required. Automation acts at an unexpected time.
- A good task gives a realistic goal without naming the solution.
- The stronger task lets the user choose a path.
- That choice is evidence.
Major section
Observe Behavior Before Opinion
People often try to be polite.
- They may say they would use a feature every day, then ignore it in field use.
- Testing should respect participant opinions while grounding design decisions in behavior.
Major section
Lab, Remote, and Field Testing
placement and visibility over time. Shared use by multiple people. Maintenance and charging behavior. False alerts and alert fatigue. Privacy comfort in a real space. Connectivity and environmental variation. Adoption after the first impression fades.
- Good review practice is to label the test type and its limits.
Try it: Lab, Remote, and Field Testing in the chapter
Major section
Iteration Decisions
Testing should end with a decision, not only a list of observations.
- Fix wording: the concept is sound but users misread a label, state, or instruction.
- Change feedback: users cannot tell whether the device heard, acted, failed, or needs help.
- Change support model: users need a handoff, escalation, or owner that the design does not provide.
Major section
Iteration Decisions (continued)
Change physical design: placement, controls, indicators, or ergonomics prevent success.
- Increase fidelity: the next question requires real sensing, actuation, installation, or field context.
- A team should loop when evidence changes the decision, but it should also name what evidence is good enough to move to the next fidelity or release stage.
- A design does not need to be perfect.
Major section
User Test Evidence Record
Task goal: the user goal being tested.
- Observed behavior: what the participant did before explanation.
- Failure state: offline, stale, low power, permission, setup, support, or other risk included in the test.
- Decision: fix, repeat a focused check, increase fidelity, field test, release with constraint, or stop.
- Change condition: the condition that requires the finding to be checked again.
Major section
Incremental Examples
A beginner test can start with a screen prototype for a visitor invite flow.
- The useful finding is the observed route and misunderstanding, not whether the participant liked the screen.
- An intermediate test adds a real or simulated reader state.
- The facilitator sets up an expired invite, a wrong-unit selection, BLE discovery failure, or gateway offline state before the task.
Major section
Worked Review: Shared Entry Setup
A team tests a shared entry reader for a small building.
- The prototype includes a mobile setup flow and a physical reader with status lights.
- Observed behavior shows that participants can invite a visitor, but they do not understand the difference between "invite sent," "visitor accepted," and "reader ready." Some assume the visitor can enter immediately.
- The design decision is not "setup works." The decision is: revise state language, add reader-status explanation, add support handoff, and check expired invite plus offline reader recovery before release.
Major section
Common Testing Defects
Testing with convenient colleagues can hide accessibility, language, age, context, role, and trust issues.
- If the facilitator tells the user where to tap, the test has become training.
- Neutral task prompts reveal whether the design communicates the path.
- IoT review should include the failure states tied to the promise.
Major section
Common Testing Defects (continued)
Setup, offline state, stale data, permission mismatch, rejected commands, and support handoff often decide whether the product feels trustworthy.
- Positive comments are useful, but they do not override observed confusion, failed recovery, or workaround behavior.
- Screen recordings alone cannot prove visibility, reach, noise, placement, installation, shared use, or maintenance access.
- If the team does not record finding, decision, owner, and change condition, the same issue can return later under a different prototype.
Deck summary
Key takeaways
hands full during entry. Weak network during setup. Device shared by several people. App permission denied. Sensor reading delayed or stale. Physical indicator hard to see. Support handoff required. Automation acts at an unexpected time.
- People often try to be polite.
- placement and visibility over time. Shared use by multiple people. Maintenance and charging behavior. False alerts and alert fatigue. Privacy comfort in a real space. Connectivity and environmental variation. Adoption after the first impression fades.
- Testing should end with a decision, not only a list of observations.
- Change physical design: placement, controls, indicators, or ergonomics prevent success.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team tests a smart access setup flow by saying, "Tap Settings, choose Visitors, then press Send Invite." Every participant completes the task. What is the strongest critique of this test?
Show answer
Answer: B A good user test gives the participant a realistic goal without teaching the interface path.
Print reference
Answers
Answer key.
- B · A good user test gives the participant a realistic goal without teaching the interface path.