Use AI to inspect UX microcopy before your next usability test

Give the reviewer the whole moment

Start with one short journey: invite a teammate, change an appointment, or save a draft. Collect the screen title, labels, helper text, buttons, error states, and confirmation. Include what happened before this screen and what the system does afterward. A screenshot alone may hide important behavior, so describe it explicitly.

Add facts the model must preserve: whether an action charges money, emails someone, changes a deadline, or can be undone. Remove identifying details from research notes and use only material your organization permits you to share with its approved AI tools. The aim is a small, accurate review packet, not an entire research repository.

Inspect before rewriting

Ask for issues first. Otherwise, a polished rewrite can conceal an invented product promise. The useful output connects an exact phrase to a possible misunderstanding, then identifies what information would resolve it. Treat statements about what users will think as hypotheses.

Use this five-part rubric: task clarity, accurate consequence, consistency, recovery guidance, and accessibility questions. Mark each item pass, revise, or unknown. An unknown about product behavior needs an owner; it cannot be repaired by choosing a friendlier adjective.

Prompt to try

Review this microcopy for the task [task]. Product facts: [facts]. Screen sequence and exact text: [text]. Do not rewrite yet. Return a table with original phrase, possible misunderstanding, relevant product fact, proposed severity, and question for the team. Check task clarity, consequences, terminology, recovery, and accessibility questions. Label predictions about users as hypotheses. Do not invent behavior or claim that this review establishes accessibility compliance.

Worked example: changing an appointment

Consider a hypothetical booking product. The heading says Change your appointment, the button says Confirm, and the completion message says All set. In this fictional system, the old appointment is released only after the new slot is successfully reserved, and an email confirmation follows.

A useful revision might be Confirm new time, followed by Appointment moved to Tuesday, 3 November at 10:00 a.m. Eastern time. Your previous appointment has been canceled. We sent confirmation to your email. Each sentence must match the implemented behavior. If email delivery is merely queued, the team should avoid claiming delivery.

Now inspect the failure state. Something went wrong offers no route forward. A candidate message is We could not reserve that time. Your original appointment is unchanged. Choose another time. That wording is appropriate only if the system actually retained the original booking. This example illustrates a review process; it is not a measured usability result.

Produce alternatives with explicit tradeoffs

Ask for two candidates rather than twenty. Keep the required meaning fixed and compare their strengths in context. Shorter copy is not automatically clearer: a date without a timezone may save space while creating a new problem. Review the full screen at mobile widths and with realistic long names and translated text where relevant.

Prompt to try

Rewrite only the approved issues below: [issues]. Preserve these verified facts: [facts]. For each item provide two alternatives, explain their tradeoffs, and list any fact still needing confirmation. Keep [terminology] consistent. Then propose three neutral usability tasks that let us observe understanding without repeating the button labels or teaching the expected answer.

Check the implementation and the person’s understanding

W3C’s form guidance recommends clear feedback about success or failure, useful correction instructions, and labels associated with their controls. Better wording is only part of that implementation. Someone still needs to check label associations, error announcements, focus behavior, and the complete interaction using appropriate accessibility evaluation methods.

In a research session, ask participants to complete a realistic task and explain what they expect before committing. Observe confusion, recovery, and whether the confirmation answers their next question. Do not turn the AI’s predictions into fabricated findings or use synthetic personas as substitute participants.

If you are new, review one form and record three questions for your team. If you are experienced, maintain a versioned content inventory with approved terminology, system states, evidence links, and ownership. Compare recurring issues across releases to improve the design system, not just the latest screen.

Try it on one real task

1. Choose a three-screen task and document exactly what each action does.
2. Run the inspection prompt and have a product owner resolve every behavioral unknown.
3. Create two copy alternatives for the highest-impact issue and test understanding with likely users.

Check before you use the result

• Every promise matches verified product behavior.
• Failure states explain the next useful action.
• AI predictions remain labeled as hypotheses.
• Accessibility implementation and user understanding receive separate evaluation.

Take the next step

Download the UX Design Coach AI practice pack for these prompts, exercises, and review checklists.

New to AI? Take the free first-workflow course at AI Teachers. Already using it? Practice building a repeatable workflow.

Sources and further reading

• W3C WAI: form notifications
• W3C WAI: labeling controls
• GOV.UK: learning about users and their needs

Sources support the principles discussed; the examples and suggested workflows are original teaching exercises.