Turn a Feature Into a UAT Plan That Tests Work

Introduced in “AI Helps Most When It Removes Handoffs Between Users and Builders.” Use it to turn a feature and its target user role into a user acceptance testing plan that tests work, not screens. Fill in the bracketed fields at the top, then send the whole template. The output is a plan for people to run; the AI doesn’t run the test and doesn’t stand in for a tester.

You help a product team design a user acceptance test (UAT).

Feature: [what the feature does, in one or two sentences]
Target user role: [the role that will use it]
Evidence behind the feature: [the observation or Product Evidence Brief]
Real setting: [where and when the work happens, volume, typical interruptions]
Planned testers: [name or role of each tester, and whether each one does this job now]
Data available for the test: [real, de-identified, or synthetic, and what it contains]

Rules:
- Use only the information above.
- Do not invent requirements, users, quotes, or numbers.
- If information is missing, write “not stated” and list it under open questions.
- Do not write step-by-step instructions for the tester.

Steps:
1. Write three to six test tasks. State each task as a goal that the user must reach.
   Do not state the steps to reach it.
2. For each task, state the realistic data that the task needs.
3. For each task, write one interruption from the real setting.
   Write when the interruption occurs.
4. For each task, write one exception that the real work contains.
5. Assign each planned tester a UAT Distance:
   D0 real user, real work, real setting;
   D1 representative user, realistic tasks, controlled setting;
   D2 subject-matter expert who does not do the work now;
   D3 customer-facing employee who simulates the user;
   D4 internal staff who simulate the user.
6. For each tester at D2, D3, or D4, write a Simulated User Disclosure:
   the role simulated, the distance, what the tester knows that the real user
   does not know, what the real user knows that the tester does not know,
   the conditions that are absent, and the decision that the result can
   and cannot support.
7. For each task, state what counts as success.
   Use completion, time, errors, and help requested.
8. Write the list of things that the facilitator must not say.
   Include hints, the location of controls, and the names of features.
9. Write the list of things that the facilitator may say.
10. List the open questions.

Output:
The test plan with sections for steps 1 through 10.

Check the plan before you schedule anyone. Every task should read as something the user is trying to get done (“get this patient’s follow-up call on today’s list”), not a click path (“select the filter menu”). If every planned tester landed at D2–D4, the plan is simulated UAT; run it if it’s useful, label it, and schedule a D0–D1 test before anyone calls the feature accepted. Read the facilitator’s “must not say” list aloud to whoever will run the session; that list prevents more contaminated results than anything else in the plan.