What Is UX Writing? How to Write Website Microcopy That Gets Visitors to Act

UX writing is the craft of writing the small words on a website, such as buttons, form labels, error messages and empty screens, so that visitors finish what they came to do. In this guide I walk through each of those microcopy types. My goal is practical: a working method you can apply to your own site tomorrow morning.

What is UX writing, and what does it cover on a website?

UX writing is the practice of designing interface microcopy (buttons, form labels, helper text, error messages, empty states and confirmations) so that people complete a task quickly, correctly and with confidence. Its measure is not a beautiful sentence. Instead, it is a finished task: was the form sent, and did anyone get stuck?

The scope is wider than most businesses assume. The big headline on your home page is marketing copy. However, the "Request a quote" button under it, the "Phone number" label in the form and the red warning after a typo all belong to UX writing. In other words, every word a visitor meets while trying to do something is part of the job.

I have built and audited websites since 2012. In that time, these tiny texts have consistently received the least attention. A designer draws the box, a developer drops in a placeholder word, and that word then stays live for years. That is why I treat UX writing as part of the interface itself, not as decoration.

How is UX writing different from copywriting?

Both work with words, but their goals differ. Copywriting attracts attention and persuades. UX writing, on the other hand, clears the path for someone who is already persuaded. The first answers "why should I choose you?" The second answers "what do I do now?" The table below shows how I see the difference in daily work.

In short, the two disciplines complement each other. Strong promotional copy brings a visitor to the form. Still, one vague label inside that form can waste all that effort at the last step. Brand voice and tone are a separate topic; this guide stays with functional text only.

Why does microcopy have such a big effect on conversions?

Because microcopy is read at the moment of decision. Visitors usually skim long paragraphs. By contrast, they almost always read the two words on the button they are about to press. If those words are unclear, hesitation starts. Hesitation is often the first step toward leaving.

Here is a pattern I see often. A business raises its ad budget and traffic arrives, yet the form does not get completed. A heatmap then shows visitors pausing at one specific field. More often than not, the problem is not the design. Instead, it is a label that never explains what the field wants. Therefore fixing the words is one of the cheapest conversion wins available.

This matches what I described in my article on UX mistakes that kill sales. Visual errors get noticed. Text errors, however, quietly cost you visitors. Moreover, a copy change usually takes a developer minutes, so the risk is low and the learning is fast.

What are the four qualities of good microcopy?

I run every piece of microcopy through four filters. They are not a rulebook. Instead, they are a quick way to settle debates at the table. The order also matters: clarity always beats brevity.

• Clear: Readers can interpret the text in only one way. What exactly does "Submit" submit?
• Concise: You cut every word you can remove without losing meaning. You never cut information, though.
• Useful: The text makes the next step easier. Polite filler takes space and adds nothing.
• Consistent: You give the same action the same name everywhere. One page never says "Cart" while another says "Basket".

For example, "An error occurred" is short. However, it is neither clear nor useful. "Card number must have 16 digits" meets all four criteria. So when I review a line, I first ask: does the reader now know what to do? If the answer is no, word count stops mattering.

How should you write button text?

Write a button as the name of what happens when someone clicks it. Generic verbs like "OK", "Submit" or "Next" do not describe the outcome. Instead, use phrases that pair the action with its object, such as "Get my quote", "Confirm booking" or "Download invoice".

I will not cover the persuasion side of buttons here. Colour, placement and examples live in my guide to call to action button examples. From a microcopy angle, three rules stand out:

1. Match the button to the heading above it. If the heading offers a free consultation, the button should not say "Buy now".
2. Name irreversible actions plainly. Write "Delete account permanently" rather than just "Delete".
3. Use verbs on both buttons in a dialog. "Delete draft / Keep editing" is easier to decide than "Yes / No".

In addition, the button and the next page title should agree. If someone clicks "See prices" and lands on a contact form, trust drops. Put simply, a button is a small promise, and the next screen has to keep it.

What makes a good form label and helper text?

A form label tells people what a field wants at a glance. It also stays visible after they start typing. The most common mistake is using grey placeholder text inside the field as the only label. That text disappears as soon as someone types. Then they have to delete their entry to remember what the field asked.

The W3C accessibility standard, WCAG, includes a success criterion requiring labels or instructions whenever content asks for user input. Likewise, the web.dev forms course from Google recommends a visible label for every field. Therefore I always place the label above the field.

I add helper text only where it truly helps. For instance, a note under "VAT number" saying "Sole traders can leave this blank" prevents many phone calls. You should also mark required and optional fields clearly. I cover the structure of booking, quote and demo forms in a separate article on lead form design.

How do you write an error message that helps?

A good error message does three things. It says what went wrong, it explains how to fix it, and it does not blame the user. The WCAG error identification criterion asks that automatically detected input errors be described in text. In practice, a red border alone is not enough.

The UK government's GOV.UK Design System has clear guidance on error messages. It favours short, plain language without technical jargon. In my own projects, I follow this order:

1. Show the error right next to the field. Do not let it hide at the top of the page.
2. Describe the problem concretely. Write "Email address is missing an @" instead of "Invalid input".
3. Give the fix in the same sentence, for example "Password needs at least 8 characters".
4. Avoid blaming phrases such as "You made a mistake".
5. Keep whatever the user typed, so they can correct it in place.

The same principle applies to server errors. "Error 500" tells a visitor nothing. Instead, try "We could not connect right now. Your details are saved, so you can try again in a few minutes." That line explains the situation and also lowers anxiety.

What should you write on empty state screens?

An empty state is the screen people see when a list has nothing in it yet. Think of an empty cart, a search with no results, or a customer dashboard before the first order. Many sites simply show "No records found". Yet this screen is a valuable chance to show people what to do next.

Good empty state copy has two parts: a short sentence explaining the situation and an action that offers the next step. For example, an empty cart can say "Your cart is empty. Browse our most popular products" with a button below. Similarly, a search with no results can suggest spelling fixes or popular categories.

• First use: Explain what will appear here and how to get started.
• No results: Repeat the search term and offer other routes.
• Cleared list: Confirm the task is done with a positive line.

That said, teams often want to make empty states funny. A joke read once can be charming. However, a customer who sees the same screen every day will tire of it quickly. So I put direction ahead of humour.

Why do confirmation and success messages matter so much?

When someone sends a form, their first thought is "did it actually go through?" A vague confirmation leads to duplicate submissions or phone calls to double check. As a result, the confirmation message is one of the most read and least valued texts in the whole flow.

A strong confirmation answers three questions: what happened, what happens next, and when. "Thanks" alone is not enough. Instead, write something concrete like "We have your request. On working days we reply by email the same day." Also, pick a response time you can genuinely keep.

The confirmation page matters for measurement too. I often attach conversion tracking to it, so you plan the copy and the tracking together. To decide which action counts as a conversion, see my guide on how to set website conversion goals.

What should you tell users while something is loading?

Waiting is the moment when users are unsure whether the system is working. A spinning icon alone creates doubt. During payments or file uploads, people may refresh the page or press the button again. A short status line reduces that risk.

For example, writing "Processing your payment, please keep this page open" on the checkout step helps prevent double charge complaints. For uploads, give progress in steps or percentages, such as "2 of 3 files uploaded". That way people can estimate how long they will wait.

Still, these lines do not replace speed. You cannot rescue a slow page with a nice waiting message; you fix the speed first. I explain how I measure performance in my Lighthouse performance test guide. For unavoidable waits, though, the right words noticeably extend people's patience.

How do multi step forms need progress text?

Splitting a long application or quote form into steps lightens the load. However, without good progress text, the structure confuses people. If users do not know how many steps remain, they may abandon the form on the second screen.

I build progress text on two facts: the current step and the total. A heading like "Step 2 of 4: Contact details" states both position and content. In addition, each step name warns people in advance what information it will ask for. As a result, nobody feels ambushed.

• Name steps with nouns: "Project details", "Budget", "Contact".
• State on the back button that entered data will stay saved.
• Show a summary on the last step with an "Edit details" option.

For instance, on a budget step, a note like "No exact figure needed; a rough range is fine" removes a lot of hesitation. In my field experience, the budget question is one of the fields where people most often drop off. So I pay special attention to the text beside it.

Which microcopy is critical on the checkout page?

Checkout is where hesitation peaks. Before typing card details, people have questions. What is the total? Will shipping be added? Can I return it? Is my data safe? You answer those questions with microcopy, exactly where each question arises.

I place tax and shipping notes right under the order total. Next to the card field, I add a short line naming the payment provider. I also show the amount on the pay button itself. A label such as "Pay $120" removes the fear of a last minute surprise. The amount here is only an illustrative example.

Payment errors make wording even more important. Instead of "Transaction failed", write "Your bank declined the payment. Check your card limit or try another card." That line gives people a way forward. If you want to review the whole flow end to end, we can work on it through ecommerce consulting.

How does UX writing change on mobile?

On mobile the screen is narrow, the finger is wide and attention is split. Together, these three conditions push you to shorten microcopy even further. A button that fits on one line on desktop can wrap onto two lines on a phone. So I check every line at the narrowest screen width.

The keyboard type is also part of the copy on mobile. A phone field should open a numeric keypad, and an email field should open a keyboard with an @ key. You set this with HTML input types and autocomplete attributes, which the web.dev forms course also recommends. The right keyboard reduces wrong input. Consequently, you need fewer error messages.

The principle from my article on mobile first design applies here too. Write for the smallest screen first, then expand for larger ones. If you work the other way round, meaning gets lost during shortening.

How do accessibility and UX writing work together?

Accessible text lets people who use screen readers, who cannot tell colours apart, or who read in a second language complete the task too. Their needs are simply an amplified version of everyone's needs. Therefore accessibility fixes help every visitor.

• Never show an error through colour alone; always add text.
• Replace context free link text like "Click here" with words that say where the link goes.
• Give icon buttons a name that screen readers can announce.
• Avoid abbreviations and internal jargon; use the customer's own words.

For example, an internal code on a shipping tracker means something to your team, but nothing to a customer. Also, short sentences help people with reading difficulties. They equally help anyone skimming quickly on a phone.

Does UX writing affect SEO?

Not as a direct ranking factor, but indirectly, yes. Google states in its page experience documentation that its systems aim to reward content that offers a good page experience. Clear microcopy is part of that experience.

In practice, I see this pattern. When visitors cannot find what they need or get stuck in a form, they leave. Even if that behaviour is not a direct signal, it is a lost customer for the business. In addition, descriptive anchor text in internal links tells both users and search engines what a page is about.

I cover where SEO and user experience overlap and where they diverge in my guide on how to balance UX and SEO. In short, UX writing does not replace SEO work. Instead, it keeps you from losing the traffic that SEO brings. If you want help on the organic side, see my SEO consulting page.

How can you test microcopy?

Rather than debating copy in a meeting, show it to real users. The simplest method is to show a screen to five people from your audience and ask: "What do you think happens when you press this button?" If their answers differ from your intent, change the text.

With enough traffic, you can also run an A/B test. However, microcopy differences are often small, so reaching a result can take a long time. For low traffic business sites, I start with qualitative methods instead. Those include session recordings, repeated questions in support tickets and the phrases your sales team hears most on the phone.

On the writing side, two simple tools help. You can check how easy your text is to read with the readability checker. Then you can check button and label length with the word counter. In particular, a character limit for mobile buttons prevents layout breaks from the start.

How do you build a content inventory and glossary?

A content inventory is a single table listing every piece of microcopy on your site. Columns for page, component, current text, proposed text and notes are enough. The first time you build one, you may be surprised how many different words you use for the same action.

When I build an inventory, I follow this order:

1. Walk through every form, dialog and alert, and take screenshots.
2. Write each text into the table and note where it appears.
3. Group different words for the same action and choose one term.
4. Add the chosen terms to a glossary your whole team can access.
5. Work with your developer to keep strings in one file and reduce hard coding.

This glossary is a lifesaver on multilingual sites. Translators take each term from one place, so a "Get a quote" button does not turn into three different phrases in another language. Moreover, when someone adds a new page, the designer knows which word to use without a debate.

How should you write microcopy that will be translated?

If your site runs in several languages, write the source text with translation in mind. Short English phrases often grow when translated. German and Turkish buttons, for instance, can become much longer than the English original. So you leave room in the layout rather than designing to the exact width of the English word.

Next, avoid idioms and wordplay in functional text. A clever phrase that works in English may have no equivalent elsewhere. Also, never build sentences by gluing fragments together in code. Word order changes between languages, so fragments that read well in English can become nonsense after translation.

Finally, test the translated interface on a real screen before launch. I have seen translated error messages that were grammatically correct yet cut off halfway by a fixed width box. Tools like a case converter help when you need to normalise capitalisation in bulk. Above all, keep your glossary as the single source of truth for every language.

What UX writing mistakes do I see most often?

The same mistakes repeat with surprising regularity on the sites I audit. The list below comes from my own field observations. You will not find all of them on every site, but you will likely find a few.

• Placeholder text such as "Lorem ipsum" or "Button" left live after development.
• System alerts appearing in a different language from the rest of the site.
• Placeholder text used instead of a proper label.
• Generic messages like "Something went wrong" with no fix offered.
• Forms that show no confirmation and simply reload the page.
• The same action carrying different names on different pages.

What these mistakes share is that copy was left until the end of the design process. That is why I bring copy to the start of a new project: we agree on the words before drawing the box. Likewise, working with real text during Figma web design prevents overflow and wrapping problems later.

Who should own UX writing in your team?

For a small business, hiring a dedicated UX writer is rarely realistic. In that case, split the responsibility between the designer and the product or marketing lead. What matters is that the copy has an owner. Someone has to say, "the words on this screen are my responsibility."

On larger projects, I treat copy as part of the design team. That is because microcopy is tied to component behaviour. When does the error appear? When does the button become disabled? Where does the confirmation show? You cannot write good copy without knowing those answers.

If you are building or rebuilding a site, a web design project that includes copy from the start costs far less than fixes after launch. I also listed the questions to ask before hiring a designer in my UI/UX design services checklist.

Which checklist should you use before launch?

Before launching any new page or form, I ask the questions below in order. I kept the list short on purpose, because nobody on a team reads a long checklist to the end. If you can answer yes to all of them, your microcopy stands on solid ground.

• Does each button say what happens when someone clicks it?
• Do form fields keep a visible label after typing starts?
• Does every error message give both the problem and the fix?
• Do empty screens show users a next step?
• Does the confirmation explain what happens next and when?
• Is the same action named the same way across the whole site?
• Can you read every line on the narrowest mobile screen without wrapping issues?

Finally, treat this list as a habit rather than a one off task. Run it again whenever you add a new campaign, payment method or form. That way, UX writing becomes a lasting quality routine for your site.

If you are unsure where to begin, start with your most visited form. First, write all its text into the inventory. Then ask the seven questions above one by one. Once you have fixed a single form end to end, applying the same method to the rest of the site becomes much easier.