UX Writing Is Infrastructure: The Words Users Actually Read

A user pauses with the cursor over a button that says "Submit." They have filled out the form, they are one step from your activation metric, and nothing on the screen tells them what the button will actually do. Save a draft? Publish to the whole team? Start a subscription? The safe move is to do nothing, so they close the tab. Your analytics records a drop-off at step four, and nobody in the company ever learns that one ambiguous word cost them the account¹.

That scenario is the whole case for UX writing in one paragraph. The words on and around your controls are not a decorative finish applied after the interface is done. They are the part of the interface a user actually reads, and they sit at exactly the moments where a person decides whether to keep going. Get them wrong and you leak users quietly at every step. Get them right and you remove friction that a redesign would take a quarter to address, for the cost of an afternoon¹.

This article is a field guide to that layer. I cover what microcopy is and where it hides, the three shapes that most interface copy should take, why plain language is an accessibility mechanism and not a style preference, how the words fit into your design system, and what changes now that AI is rewriting the economics of content. Every claim traces to a live source, and the practical advice is copy you can lift directly.

The words users actually read

Users do not read interfaces. They scan them. Nielsen Norman Group has measured for years that people read only about 20 to 28 percent of the words on a web page, and they read them to complete a task, not to admire your prose². That single fact changes what good interface copy looks like. Long explanatory paragraphs are dead weight. The words that earn their place are the short ones at decision points: the button label, the field hint, the error under a form, the empty state on a screen that has nothing in it yet, the confirmation before an irreversible action.

Call this layer microcopy and you risk underselling it, because the label makes it sound small. It is small in length and huge in leverage. Microcopy is the text at the decision points, and its failure modes are all the same shape: the product knows something the user does not, and it declines to say it¹. A button that just says "Continue" knows whether continuing means paying, saving, or deleting, and withholds that. An empty state that says "No data" knows what the screen is for and what the user could do first, and withholds that. An error that says "Invalid input" knows which field failed and how to fix it, and withholds that.

The fix is not to write more. It is to write the specific thing at the specific moment. The formula for buttons is verb plus the user's outcome: "Create my first report" instead of "Submit," "Send 12 invitations" instead of "Confirm," "Delete 3 reports" instead of "OK"¹. The label should survive being read alone, because it will be read alone, and it should make the consequence obvious before the click, especially where money or deletion is involved.

The three shapes of interface copy

Most microcopy is one of three shapes, and once you see them they cover almost every surface. Buttons are verb plus outcome. Errors are what happened, why, and what to do next. Empty states are what this screen is for, the payoff, and one action¹.

Error messages carry the most weight, so they get the most discipline. A good error message is one short, plain sentence that states the problem and points to the fix³. "That file is 12 MB; the limit is 5 MB. Try compressing it or uploading a CSV" does the whole job. "Error 422: unprocessable entity" does none of it¹. Three rules govern errors. First, never lead with a code, because a code tells a user nothing about what happened or how to fix it³. Second, never blame the person reading it. "You entered an invalid ZIP code" scolds; "We couldn't find that ZIP code. Please enter a 5-digit ZIP" describes the issue and gives the fix³. The word "invalid" should not appear, because it names no real problem and no real solution. Third, put the message next to the thing that failed, in the user's language, and tell them what to do next, without forcing them to leave the screen or contact support to recover¹.

Placement is part of the craft. The message belongs adjacent to the field or action it concerns, not in a banner at the top of a long form where the user must hunt for which field went wrong³. Show errors inline as the user leaves a field, so they correct the mistake while the context is fresh, rather than after a submit that resets the form. And never rely on color alone to signal an error; include text a screen reader announces and an icon for users who cannot see red³.

Empty states are the highest-traffic onboarding surface in your product, because they are the first thing a new user sees on every empty screen¹. A blank screen with a good sentence and one button converts. A blank screen that says "No data" is a dead end you paid to build. The winning shape is three sentences and a button: what this screen is for, the payoff, and the single most useful next action¹. Instead of "You have no projects," write "Projects keep your work separate per client. Create your first one." Instead of "No results found," write "No reports match those filters. Try widening the date range." The button should be the most useful action, not a link to documentation.

Plain language is an accessibility mechanism

Here is where UX writing stops being a copy concern and becomes an accessibility obligation. Plain language is not a soft preference for people who dislike big words. It is the mechanism that makes WCAG's "Understandable" principle real, and it is now entangled with deadlines that carry legal weight⁴.

WCAG organizes accessibility around four principles: Perceivable, Operable, Understandable, Robust. Content teams live in Understandable, which is success criteria 3.1 through 3.3⁴. Three of those criteria are, in effect, writing standards. 3.1.5 Reading Level says write so people can understand, or offer a simpler version; that is literally your readability score. 3.2.4 Consistent Identification says call the same thing the same name everywhere, so your "Submit" button cannot morph into "Send" two screens later. 3.3.2 Labels or Instructions says tell people exactly what you need from them, and "Enter your information" does not cut it⁴. Plain language is how you meet all three.

The stakes are concrete. The DOJ's ADA Title II rule requires WCAG 2.1 Level AA for state and local government digital content, with compliance deadlines in April 2027 and April 2028⁴. The EU's EAA deadline for accessibility of products and services, which we covered separately, has already made accessibility a legal requirement for a wide class of software in Europe. Teams that wait for an audit to discover that their carefully written copy breaks 3.3.2 are learning an expensive lesson about what accessibility actually includes.

The evidence that plain language works is not just doctrinal. A 2024 randomized trial found that health information revised for plain language dropped the reading grade level by nearly three full grades while retaining all key content, with complex language and passive voice decreasing and expert reviewers rating the simplified versions higher for clarity⁴. Canada published its first national plain language standard in October 2025, which names the exact barriers plain language addresses: barriers to understanding, barriers to attention, and barriers to finding what you need⁴. This is a recognized discipline with standards and research, not a stylistic whim.

The words belong in the design system

If you treat UX writing as ad-hoc sentences typed by whatever engineer ships the screen, you get the consistency disaster that WCAG 3.2.4 exists to catch. Different teams call the same feature different names, error messages vary in tone and structure, and a user builds a wrong mental model of your product that produces support tickets forever¹.

The fix is to treat content as part of the design system, which is exactly what your design tokens already do for color and spacing. The component libraries you choose should ship with pre-approved, accessible microcopy and patterns, so teams are not reinventing button labels and error messages on every screen⁴. This connects directly to our design-system release discipline work: when you update a component's copy, it is a change that ripples through every consuming product, and it deserves the same classification and deprecation treatment as a visual or behavioral change.

Content in a design system needs an owner. UX writing covers voice and tone, terminology systems, information hierarchy, and the decision of whether a screen needs words at all. Microcopy is the concrete output of that practice at the level of a button, a hint, or an error¹. In small teams the distinction rarely matters. What matters is that someone owns the words with the same seriousness the interface gets, and that the ownership is documented rather than carried in one person's head.

What AI changes, and what it does not

The 2026 story in this space is how AI is reshaping the economics of content, and the honest take is that it changes the methods, not the problems. Patrick Stafford of UX Content Collective, writing a January 2026 state of the field, makes two points that reframe the whole job⁵.

First, text is infrastructure. Content design is moving closer to engineering over time, and it helps to think of text as a layer of code rather than as purely creative work⁵. You do not need to spend the same emotional energy on an error message that you spend on an onboarding flow; you need it to be correct, consistent, and documented. Second, the way content designers work with AI has moved past prompting. The useful skill now is context engineering: building a repository of guidelines, instructions, and patterns that AI tools can use, so your delivery is informed by your actual standards rather than by whatever the model improvises⁵.

That shift makes documentation more important than ever, which is a painful realization for most teams. Content design relies on patterns that are implicit in the writing process, and those patterns are exactly what an AI tool needs to be told. If your voice and tone, your content patterns, and your error-message structure are not written down, no assistant can follow them⁵. The practical move is to write these rules down as markdown files that can move across tools and contexts, which is the same discipline that makes your content reviewable and your design system maintainable.

None of this replaces the content designer. The people having the most impact are the ones leaning into the tools while keeping their core skills sharp: reading the content mess, testing methods, turning user feedback into action, and demonstrating impact⁵. AI writes more of the experience every quarter, and the writing still has to be good, because users notice bad writing far more than they notice whether a machine produced it⁶.

Measuring the words

The reason UX writing often goes unowned is that its impact is hard to point to after the fact. But it is measurable, and the numbers are convincing. An e-commerce company that rewrote its checkout error messages to provide specific solutions instead of generic errors saw a 25 percent reduction in support tickets related to payment issues⁷. Companies that A/B test their microcopy routinely find that small copy changes drive conversion improvements in the 5 to 25 percent range⁷. In a documented Booking.com case study, simplifying copy and removing unnecessary text elements led to a 5 percent increase in conversions⁷.

Microcopy is also the cheapest interface change to test, because it is the only part of the interface you can change, measure, and change again in the same week, without a design system revision or an engineering quarter¹. When your analytics show a stall at one step and the design looks fine, the words are usually the suspect. Rewrite them before you rebuild anything. It costs a day and it rules out the likeliest cause.

A decision rule for your team

The whole discipline compresses into one operating rule: whenever a user hesitates at a button, misreads a field, or hits an error they cannot interpret, the words at that moment are a design defect, not a copy afterthought. Fix the words first.

Concretely, start with the highest-leverage surfaces. Run an audit of your empty states, because they are your highest-traffic onboarding and the easiest to get right. Rewrite your error messages to the what, why, next shape in plain language, next to the thing that failed, and watch your payment-related support tickets. Standardize your button labels so they name the outcome, and so the same action reads the same everywhere. Write down your content patterns as markdown so an AI tool can follow them and a new teammate can learn them. Then measure completion, support tickets, and A/B test results, and let the numbers make the case for the next round.

The words are part of the interface. They are the cheapest, most testable, most underused lever you have, and every user you keep at a decision point is a conversion you did not have to redesign for.