UX Copy Inventory: Audit Labels Across Product Flows

A UX copy inventory is a structured list of the words people encounter while completing a product task. It connects each label, message, and instruction to its screen and trigger, so designers can fix inconsistent terms and missing recovery guidance in context.

Use a Pixso UX design collaboration workspace to review the inventory beside the screens that use it. The example below follows a team administrator inviting a colleague, from entering an email address to confirming that an invitation was sent.

1. Set the inventory boundary

Choose one journey and list every visible string in the order it can appear. Include navigation labels, button text, field hints, validation messages, notifications, empty states, and confirmation text. Record the screen, trigger, and user goal for each item.

For this example, an administrator invites one teammate by email and assigns a Viewer or Editor role. Only an administrator can send invitations, and an invited person becomes a member after accepting. Those are the sample product's rules; the wording should make them clear. The inventory covers the invitation flow, not the entire workspace.

Choose fields that make a string traceable

• String ID: a stable identifier such as invite.email.required, independent of the current wording.
• Screen and trigger: where the string appears and what must be true for it to appear.
• Current and proposed copy: the exact wording, including punctuation and variable placeholders.
• Meaning and constraints: the rule the string communicates, variable type, or layout requirement.
• Owner and status: who can approve the wording and whether the change is proposed, approved, implemented, or verified.

A string ID is an implementation reference, not text to show users. If the same sentence appears in two places with different meanings, keep separate records even when the words currently match.

2. Check names and actions for consistency

Compare nouns, verbs, capitalization, and tone across the journey. A “Remove” action should not become “Delete” without a product reason; a role should not mean something different on another screen. Record the preferred term and the exceptions so designers and writers can apply the distinction consistently.

In the invitation flow, “Add member” promises too much: sending an invitation does not itself create a member. “Send invitation” describes the immediate action, while “Invitation sent” describes its confirmed result. Keep “Editor” and “Viewer” identical in the role picker, helper text, and later member list.

A completed copy inventory for the invitation flow

These six records identify the text change, but they are not the complete list of strings in the flow. The inventory also needs unchanged items such as “Email address,” “Role,” “Cancel,” “Sending invitation…,” and the invitation-expiry message if the product has one. Keeping unchanged strings makes the flow understandable to the next person reviewing it.

3. Review error, empty, and permission copy

Useful copy explains what happened, what the person can do next, and whether their input is safe. Replace vague messages with a cause and recovery path when the product actually knows them. For permission errors, identify the missing access and the person or role able to provide it.

Separate a confirmed failure from an unknown result. A rejected email format can be corrected before sending. A confirmed permission denial requires an administrator. If the request times out after sending, however, the system may not yet know whether an invitation exists. Do not show “Invitation failed” and immediately offer another send unless the product can prevent duplicate invitations. A status check or a link to pending invitations may be the appropriate next action.

Write each message beside its trigger. Without that condition, a developer could reuse the permission message for a network failure, or display “Invitation sent” as soon as the request starts. Accurate copy depends on accurate state information.

4. Test length, localization, and accessibility

Check long names, narrow layouts, zoomed text, keyboard focus, and screen-reader order. Leave room for translation expansion and avoid conveying meaning only through color or icons. Record variable text and any plural or grammatical requirements before implementation.

For invite.sent, try alex.morgan+research@example.com as well as a short address. The confirmation should wrap without pushing its next action off-screen. Keep the whole sentence in one translatable string rather than joining “Invitation sent to” and the address with assumptions about word order.

If the product later supports bulk invitations, create a separate plural-aware message for the count. Do not force “Invitation sent to {email}” to describe a mixed result such as three sent and one rejected. The additional outcome needs its own record and its own recovery action.

Show an email-field error next to the field and retain a persistent label. In implementation, associate the error with that field and expose a new status message to assistive technology. The visual mockup should show the intended placement; keyboard and announcement behavior still need to be checked in the working interface.

5. Link each string to a decision

For every change, record its reason, owner, status, and affected screens. Link the inventory row to the frame or prototype state where the wording appears. This prevents a corrected label from being copied back into an older flow.

For example, assign the permission rule to the product owner, the final wording to the content designer, and the trigger mapping to engineering. Mark invite.permission.denied as approved only after those three agree on the rule. After implementation, confirm that a non-admin receives that message and that the typed email remains available. “Approved wording” and “verified in the product” are different statuses.

In Pixso, place the invitation form, invalid-email state, permission-denied state, and confirmation next to each other. Add the string IDs beside the corresponding elements and keep the inventory in the same review context. Comments can then refer to a specific message and condition rather than asking for the whole screen to sound friendlier.

Make language part of the design review

Review the inventory with design, product, engineering, and localization before strings are frozen. Resolve terms that affect several flows first, then check the approved words in their actual layouts. The useful result is a set of messages that describe the same product rules wherever they appear.

Review your invitation flow and UX copy in Pixso →