You change your billing flow so payments process in the background. The next morning your support inbox fills with the same question: “Was I charged twice?” Nothing went wrong with the payments. The confirmation screen said “Processing” and then went back to the plan page, so customers clicked “Pay” again to be sure.
That is a UX writing problem. UX writing is the practice of designing the words inside a product (button labels, form hints, error messages, empty states, confirmations and notifications) so people know what is happening and what to do next. It sits inside the design work, not after it, and it is one of the cheapest ways to improve conversion and feature adoption because you can change words without rebuilding screens.
Where UX Writing Fits in Product Decisions
Teams that treat copy as a final polish step tend to ship interfaces that look finished but explain very little. The words decide whether a screen makes sense, so they belong in the same conversations as layout and flow.
Interface guidance is a different job from marketing copy
Marketing copy persuades someone to pay attention or buy. Interface copy helps someone who has already arrived finish a task with as little doubt as possible. A clever headline on a landing page can work well. A clever label on a payment button creates risk, because the person reading it is mid-task and looking for one answer: what happens if I press this?
The two still need to agree. If your ads promise setup in five minutes, the onboarding screens have to show the steps and an honest sense of progress. When the product’s language contradicts the promise that brought someone in, trust drops before the trial has started.
Content design looks past single strings
A content designer asks what information a person needs, in what order and in which format, across a whole flow. Sometimes the right answer is fewer words: a progress indicator instead of a paragraph, a table instead of three sentences, or one fewer form field. Those decisions change the interface itself, which is why they belong in design.
Someone has to own the words before development
In larger teams a dedicated UX writer or content designer owns interface copy. In smaller teams the product manager or a UX designer usually takes it on. Problems start when nobody owns it. Developers fill gaps with placeholder text like “Item” or “Error 403”, and that text ships.
A simple rule fixes most of this: no screen moves into development without approved copy for every state, including errors, empty states and confirmations.
Which Messages to Fix First
Start where confusion costs money or support time: calls to action, form labels, error messages and the first screens a new user sees. A useful way to find them is to sort your support tickets by screen. The screens that generate “how do I” and “what does this mean” questions are where the words are failing.
Buttons and forms that make the next step obvious
A button label should name the action and, where it matters, the result. “Submit”, “Continue” and “OK” make people guess. “Create account”, “Start free trial” and “Pay $49 now” do not.
A quick test for any key flow: read only the button labels, in order. If the sequence tells the story of the task (“Add to cart”, “Review order”, “Place order”), the labels are doing their job. If it reads “Next, Next, Submit, OK”, people have to read everything else on the screen to know where they are.
Forms need the same care. Keep labels visible above fields rather than relying on placeholder text that disappears when someone starts typing. State format rules before the mistake happens. If a password needs 12 characters and a number, say so next to the field, not only after a failed attempt.
Error messages that explain and recover
A good error message answers two questions: what went wrong, and what can I do now? It also avoids blaming the user. “You entered an invalid date” assigns fault. “Enter the date as MM/DD/YYYY” gives the fix.
| Weak message | Stronger message | Why it works |
| Something went wrong. | We couldn’t save your changes because your session expired. Sign in again and your draft will still be here. | Names the cause and reassures about lost work |
| Invalid input. | Enter a 5-digit ZIP code. | States the rule in the user’s terms |
| Payment failed. | Your card was declined by your bank. Try another card or contact your bank. | Separates what you control from what the bank controls |
| Are you sure? (Yes / No) | Delete this report? This can’t be undone. (Delete report / Keep report) | Buttons say exactly what each choice does |
Place errors next to the field that caused them, keep whatever the person already typed, and never clear a long form because one field failed validation.
Empty states and first-run screens
For a new account, the empty state is often the first real screen of the product. “No projects” reads like a dead end. “Your projects will appear here. Create your first project to start assigning tasks to your team”, with a single “Create project” button, tells people what the screen is for and how to fill it.
The same thinking applies to onboarding steps: explain why each step matters, keep instructions short, and let people skip what they do not need yet. Our guide to SaaS onboarding UX design covers how those first sessions connect to activation.
Confirmations and notifications
Go back to the billing example. “Processing” told customers nothing about the outcome. “Payment received. Your receipt is on its way to [email protected]” would have closed the loop. Good confirmations name the object, the action and what happens next.
Notifications should earn their interruption. “You have a new update” makes people open the app to find out whether it matters. “Alex shared the Q3 budget with you and asked for comments by Friday” lets them decide on the spot.
If you are not sure where your product’s words are causing friction, an M7 UX audit reviews your key user flows, usability and accessibility, and the prioritized fixes we recommend regularly include rewritten labels, errors and empty states alongside layout changes.
Keeping UX Writing Consistent as the Product Grows
Without shared rules, language drifts with each release, and people start to wonder whether a “workspace”, a “project” and a “team” are three different things.
Plain language without losing the facts
Plain language means common words, short sentences and one idea at a time.
Plain does not mean vague. “Your transfer may take a while” is simple but leaves people anxious. “Transfers arrive in 1 to 3 business days” is just as plain and far more useful. Cut jargon, keep the facts people need to act, and if a technical term is unavoidable, define it the first time it appears.
Voice stays the same, tone changes with the moment
Your brand voice is constant. Tone shifts with the user’s situation. A light, upbeat line works on a welcome screen. The same tone on a failed payment feels careless. A practical approach is to map tone to moments: celebrate small wins briefly, stay calm and direct in errors, and be precise and serious around money, health data, privacy and account security.
Accessible and translatable by default
Accessible copy works for people using screen readers, voice control or keyboards. Common failures are icon-only buttons with no text label, links that say “click here”, required fields marked only by red color, and error messages that are never announced to assistive technology. The Web Content Accessibility Guidelines cover labels, instructions and error identification in detail.
Write link and button text that makes sense out of context, because screen reader users often jump between controls. For translation, avoid idioms and wordplay, leave room in layouts for longer strings, and do not build sentences by stitching variables together in ways that break grammar in other languages.
Put copy rules inside the design system
A content style guide only gets used when it lives next to the components it governs. Each component should come with copy rules: maximum label length, preferred verbs, the structure of an error message, and examples of right and wrong usage. Add a glossary of product terms so one concept keeps one name everywhere.
Teams building design systems for scaling digital products get the most from this when approved strings are stored with approved components, so engineers can pull both from the same source.
A Research-to-Release Workflow for Interface Copy
Good copy follows the same discipline as good design: research, drafts, prototypes, review and release.
Start with the user’s own words
Review support tickets, sales call notes, site search logs and session recordings to find the exact phrases people use. Their words often work better than your internal ones. A team might call a feature “Data connectors” while every customer email asks how to “link my bank”. The customer’s phrase belongs in the interface.
Then walk through the flow and mark high-risk moments: payments, deleting data, permission requests, plan changes and anything involving health or financial records. These deserve the most writing effort, because a confusing message there costs trust, money or both.
Write in the design file, then prototype with real words
Write copy directly in the design file, not in a separate document that drifts out of sync. If a label needs eight words to make sense, the interaction itself is probably unclear. Put real copy into clickable prototypes from the start, since testing with lorem ipsum hides one of the most common sources of confusion. Draft two or three versions of key messages so you have options ready to test.
Cover the edge cases and write copy into acceptance criteria
Most broken copy lives in edge cases: zero results, one result, very long names, slow connections, expired sessions, partial failures and permission limits. Review each before handoff.
Then make copy part of the definition of done. Tickets should list the exact strings for each state, mark which values are dynamic, and note how errors are announced to screen readers. When copy is in the ticket, engineers stop inventing placeholder text and QA can test the words like any other requirement.
Use AI for variations, keep people for decisions
AI tools are useful for generating label variations, shortening long strings, checking drafts against a style guide and producing first-pass translations for review. They do not know your legal constraints, your users’ worries or the product logic behind a message, and they can produce confident text that describes the system wrongly. Keep a person accountable for approving every string that ships, with extra review on sensitive flows.
How to Test Whether UX Writing Improves the Experience
Watch whether people understand the words and finish tasks, then confirm the effect in product data.
Test comprehension with real users
Run short usability sessions on the flows you changed. Give people a task, watch where they pause, and ask them to explain in their own words what a message means or what a button will do. If their explanation does not match yours, the copy needs work. Five or so participants per round will usually surface the biggest problems in a single flow, which matches long-standing Nielsen Norman Group guidance on small-sample testing.
Run A/B tests only where traffic supports them
A/B tests suit high-volume moments such as signup buttons, pricing page calls to action and checkout steps. Low-traffic admin screens rarely produce a reliable result, so test those with people instead. Change one thing at a time and choose the success metric before launch. A label that lifts clicks but increases refunds or cancellations has not improved anything.
Watch adoption and support demand after release
After launch, track the numbers your copy should move: task completion, time to first value, feature adoption, form error rates and tickets tied to a specific screen. If “how do I” tickets about one screen drop after you rewrite its error message, that is strong evidence the new wording works.
Keep a simple log of every copy change with its release date and the screen it affects. When a metric moves weeks later, the log tells you whether the new wording is a likely cause or whether something else shipped at the same time.
Make Clear Words Part of Every Release
The billing confirmation that caused duplicate payments is a one-line fix once someone owns it. Most interface copy problems are like that: small, cheap to correct and expensive to ignore. Give the words an owner, put the rules in your design system, and test copy with the same care as any other feature.
M7 builds interface copy into our UX design and product engineering work, so the labels, errors and empty states are written, tested and handed to developers alongside the screens. If your product needs clearer language as part of a redesign or a new build, see how M7 can help with your product.
Frequently Asked Questions
What does a UX writer do on a product team?
A UX writer creates and maintains the words people see inside a product, from buttons and forms to errors, onboarding and notifications. They work with designers, product managers and engineers so each step is clear and terms stay consistent. On smaller teams this work is often shared by a designer and the product manager.
Is UX writing the same as microcopy?
Microcopy is the short text in an interface, such as labels, hints and error messages. UX writing includes microcopy but also covers terminology, tone rules and the research and testing behind those choices.
Can better interface copy improve conversion without a redesign?
Yes, when confusion is the main cause of drop-off. Check recordings and tickets for the screen first: if people hesitate, misread labels or ask what something means, the words are a likely fix. If they understand the screen and still leave, the problem is usually price, trust or the flow itself, and copy alone will not solve it.
When should a team bring in a dedicated UX writer?
Consider it when people stall in key flows, support keeps answering the same questions, or terms vary from feature to feature. Earlier is better, ideally during discovery and prototyping, because fixing copy debt across a large product takes far longer than preventing it.
