A participant smiles at an AI response and says, “That’s pretty cool.” It is a lovely moment. It also leaves several important questions unanswered.
Do they understand its limitations? Can they notice a problem? Do they know what they can change? Can they continue after rejecting a suggestion?
AI usability testing should examine those questions alongside satisfaction and task completion. Delight deserves a seat at the table. It should not be the only person taking notes.
Choose a research question
Start with a decision the team needs to make. For example: “Do people understand that a generated summary needs review before sending?”
This suggests a task involving review and sharing. It also defines what to observe: how someone evaluates the content and what they believe the system has verified.
If a label is expected to communicate a limitation, treat that expectation as something to test.
Use tasks that reveal judgement
Here is an illustrative outline for testing an AI writing feature:
- Understand: ask someone to produce a short summary and observe what they expect.
- Review: provide a result with an intentional, low-risk inconsistency and ask them to prepare it for sharing.
- Correct: ask them to change one part while keeping the rest.
- Reject: explain that the suggestion does not fit their needs and observe their next step.
- Recover: introduce a controlled technical failure and examine whether progress and choices remain understandable.
These are proposed tasks, not findings from a completed study. Adapt them to the real product and users. Explain relevant simulation details, avoid unnecessary sensitive information and debrief participants about intentionally flawed content.
Observe behaviour before asking for opinions
Ask people to explain what they think will happen before a consequential action. Then observe what they do.
Note uncertainty, repeated checking, workarounds and acceptance without understanding. A final successful click can hide substantial confusion along the way.
Use neutral prompts such as “What are you considering here?” Avoid naming the control you want them to find. The prototype is taking the test; the participant is helping you understand it.
Separate the measures
- Completion: did they accomplish the intended task?
- Comprehension: could they explain the system’s role and relevant limits?
- Control: could they edit, reject or choose another path?
- Recovery: could they continue after a flawed result or failure?
- Confidence: did their certainty match what they understood?
A small qualitative study can reveal useful problems. It does not establish a population-wide percentage or prove a revenue effect. Report observations, context and limits separately.
Include different access needs
Review relevant assistive technology and involve people with disabilities. Check whether dynamic feedback is understandable and editing works beyond a mouse-based path.
The Microsoft HAX Toolkit offers reference material for human-centred AI design. Research should examine how those questions apply to the actual product.
My Nebula case shows research informing a learning experience. The AI recovery checklist can help choose a failure state to investigate.
For your next session, choose one question: “Does the person understand enough to make this decision?” That small sentence contains a surprisingly useful amount of work.