Readability and Plain Language

Microcopy Clarity Test

Test whether labels, buttons, hints, errors, confirmations, and warnings communicate meaning, consequence, status, and the appropriate next action.

Free editable Markdown · Content designers, UX researchers, and product teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

String and scenario

String ID: [Design-system or product identifier]
Current copy: [Exact text]
Component and state: [Button, hint, error, warning, confirmation]
User goal: [What the person is trying to do]
Required meaning: [What they must understand]
Consequence: [What happens after action or inaction]
Surrounding context: [Labels, values, status, or help]
Risk if misunderstood: [Low, medium, or high with reason]

Test plan and observation

Participant profile: [Relevant experience and access needs]
Task prompt: [Neutral, realistic scenario]
Prediction question: [What do you expect this will do?]
Success behavior: [Observable action and explanation]
Observed hesitation: [Where and how long]
Wrong interpretation: [Participant's words]
Recovery behavior: [Could they proceed safely?]
Accessibility observation: [Order, announcement, focus, or input]

Decision checks

The task prompt does not reveal the intended label meaning.
Testing occurs in realistic visual and system context.
Consequential and error states are included.
Copy problems are separated from interaction problems.
The revised verb and object describe the action.
Destructive effects are explicit before commitment.
Terminology remains consistent across the journey.
Retest, translation, and ownership decisions are recorded.

How to use this template

Inventory the target string, interface state, user goal, consequence, and expected interpretation.
Create realistic tasks and states without revealing the answer in the prompt.
Observe predictions, actions, hesitation, errors, recovery, and participant explanations.
Diagnose copy versus interaction problems and draft focused variants.
Retest high-risk changes and record the approved string, rationale, owner, and locale implications.

Define what the copy must enable

For each string, record the user state, goal, available context, and consequence of misunderstanding. A button should describe the action, an error should explain what happened and how to recover, and a confirmation should state the new status. Determine what a participant should predict before acting and recognize afterward. Avoid testing personal preference such as “Which sounds friendlier?” when the real question is whether the person chooses the correct action and understands its effect.

Test in sequence and under pressure

Place the string in a prototype or product flow with realistic surrounding labels, values, and system state. Ask participants to think aloud or explain what they expect, then observe behavior without teaching the intended answer. Include important boundary states: empty input, invalid value, waiting, lost connection, insufficient permission, destructive action, and success. Test keyboard and assistive-technology output where relevant because visible proximity may not match announced order. Record hesitation, wrong paths, and recovery, not only task completion.

Revise the smallest useful unit

Diagnose whether failure belongs to the words, information order, interaction, visual hierarchy, or missing system capability. Copy cannot repair a control whose consequences are inherently hidden. Draft variants that change one meaningful feature at a time: verb, specificity, timing, consequence, or recovery instruction. Recheck consistency with product terminology and translations. When a label is necessarily short, use nearby help or confirmation rather than squeezing every condition into the button.

See the fields in context

Fictional example: shared list removal

GatherList is an invented application, and the test observations are illustrative.

Current button: “Remove,” shown beside a fictional shared list.
Observed interpretation: Two fictional participants think it removes only the list from their own sidebar.
Actual consequence: The action would delete the list for all members, so the interaction is high risk.
Revision: Button becomes “Delete shared list,” followed by a confirmation naming the list and affected team.
Retest outcome: Participants accurately describe the shared consequence before confirming with non-production data.

Frequently asked questions

How many participants are required?

Choose a number appropriate to the decision and diversity of relevant contexts. Small qualitative sessions can reveal problems but should not support population-wide performance claims.

Should a button label include the result?

Use a specific verb and object. For complex or destructive consequences, pair the label with nearby explanation and a well-designed confirmation.

Can preference testing select the clearest copy?

Preference alone does not show comprehension. Ask participants to predict consequences, choose an action, and explain the resulting state.

Do translated strings need separate testing?

Yes when the workflow is important. Length, terminology, grammar, cultural expectations, and screen-reader output can change clarity in each locale.