Test Non-Deterministic Flows and Measure Trust

Workflow area: AI-UX Evaluation · Tier: Advanced · Hands-on time: ~45 minutes

Run a standard usability test on an AI feature and the data dissolves: participant one gets a brilliant response, participant three gets a mediocre one, and your task-success rate measures the model's mood, not the design. Meanwhile the metric that actually predicts outcomes — whether users trust the feature appropriately — never gets measured, because traditional protocols have no instrument for it. Both over-trust (accepting fabrications) and under-trust (re-verifying everything, abandoning the tool) are design failures with different fixes. This playbook rebuilds the protocol: success defined over outcome classes, failures injected on schedule, and trust measured as calibration, not sentiment.

When to use — and when not to

• Use it for any moderated test of a generative featureif two participants can see different outputs for the same task, the classic protocol is already broken; adapt before you recruit.
• Use it when you need failure-response datawaiting for the model to fail organically during sessions wastes participants; injection guarantees every participant meets the states you designed in pb-48.
• Use it when trust is the open questionpost-launch surveys say "users don't trust it" or "users over-rely on it"; this protocol localizes which, where, and how much.
• Skip it for deterministic UI around the AItesting whether people can find the settings screen or read the activity log is classic usability; don't complicate it.
• Skip trust batteries in five-minute unmoderated testscalibration measurement needs verification tasks and time; in a short Maze test, stick to findability and first impressions.

The recipe

1. 1.

   Rewrite task success as outcome classes. For each test task, stop defining success as "reached the correct answer" and define three to four classes any session can be scored into, regardless of what the model produced: Class A — good output, recognized as good, used appropriately; Class B — flawed output, flaw detected, user recovered (edited, regenerated, verified); Class C — flawed output, flaw missed, used anyway (the over-trust signal); Class D — good output, distrusted and discarded or laboriously re-verified (the under-trust signal). Note the inversion: Class B is a design success — the feature helped the user catch the model. C and D are the failures, and they're invisible to a pass/fail rubric.

2. 2.

   Script failure injection. Don't hope for failures — schedule them. Prepare a prototype (Figma Make with canned responses, or a Wizard-of-Oz setup) where tasks 2 and 4 return planted flaws drawn from your pb-48 map: one wrong-but-plausible fact, one stale claim, one incomplete answer. Every participant now encounters identical failures at identical moments, which makes detection rates comparable. Keep one genuinely live task so you also observe real variance — label it as such in analysis.

3. 3.

   Generate the moderator guide with AI, then tune the probes.

   Copy

   You are a UX researcher designing a moderated test for an AI
   feature with non-deterministic output.
   
   Feature: [DESCRIPTION]
   Planted failures: [LIST: task, flaw, what detection looks like]
   Outcome classes: [PASTE YOUR A/B/C/D DEFINITIONS]
   
   Produce a 45-minute moderator guide:
   1. Tasks with scenario framing that does NOT prime skepticism
      (no "check whether it's right" language).
   2. For each task: behavioral observations to log (verified
      sources? edited before use? regenerated?), and the outcome-
      class decision rule.
   3. Non-leading probes for after each task: gauge perceived
      reliability WITHOUT asking "did you trust it?" directly.
   4. A closing trust battery: 5 questions on reliance intent
      ("which of today's outputs would you send to your manager
      unedited?") rather than sentiment.
   Flag any question wording that risks demand characteristics.
   

   The critical property: tasks must not warn participants that outputs may be flawed, or you'll measure primed vigilance instead of natural reliance.

4. 4.

   Measure trust as calibration, not affection. From the sessions, compute: detection rate — share of planted flaws caught (per flaw type, since stale and wrong-but-plausible detect differently); verification behavior — how often users checked sources or facts, on flawed and clean outputs; reliance decisions — the "send unedited?" answers against output quality. Then place each participant on the calibration grid: trusted-good + caught-bad is calibrated; trusted-everything is over-trust; verified-everything is under-trust. Your product metric is the share of users in the calibrated cell — a number you can move with design (provenance UI, hedges, onboarding) and re-measure.

5. 5.

   Turn C and D cells into design actions. Over-trust (C) points at missing friction: sources not shown by default, confidence displayed decoratively, flawed outputs looking identical to good ones — pull pb-48's preventive designs. Under-trust (D) points at missing reassurance: no provenance to check quickly, past failures without visible repair, hedging so uniform it reads as incompetence. Write one design change per non-calibrated cell before the next test round — the protocol is a loop, not an event.

Make it yours

• Maze for the unmoderated slice: run findability, first-use comprehension and the pb-40 empty-state test unmoderated at volume; reserve moderated sessions for injection and calibration, where the observer matters.
• UserTesting for longitudinal trust: trust calibrates over exposure — panel five users across three sessions a week apart with fresh planted flaws each time, and watch whether detection improves (learning) or decays (complacency).
• Claude as session analyst: paste anonymized session notes and per-task observations, and ask for outcome-class assignments with the evidence for each — then audit its calls; disagreements sharpen your class definitions the same way rubric disputes did in pb-49.

Quality check

• Success is scored in outcome classes, not pass/faila session where the user caught a planted flaw scores as a design win, and your report explains why.
• Every participant met identical planted failuresdetection rates compare like-for-like; the live task is analyzed separately.
• Task framing didn't prime skepticismno instruction hinted that outputs might be wrong; vigilance observed was natural, not staged.
• Verification was observed on clean outputs toounder-trust is invisible unless you watch people distrust good answers.
• Trust metrics are behavioraldetection, verification and reliance decisions, not "how much do you trust this, 1–7" alone.
• Each non-calibrated cell produced a design changeC and D findings landed in the backlog with a named pattern fix, not a "users should be more careful" shrug.