Guide · UX and content

UX writing: how to write microcopy that makes your product easier to use

UX writing is the short text inside an interface: buttons, field labels, error messages, confirmations and empty screens. Good microcopy tells users exactly what is happening and what to do next, in as few words as possible. This guide gives you the principles, a before/after table with real examples, rules for Danish tone and a checklist for your own product.

11 min read · Updated 1 October 2026

Picture a customer who has filled in an order form with twelve fields. She presses "Submit", and at the top of the page it says in red: "An error occurred". No explanation, no highlighted field, and half of what she typed is gone. She phones your customer service, or she goes to a competitor. Neither shows up in your analytics as "bad copy", but that is exactly what it is. UX writing is about the few words that decide whether people get through, and it is one of the cheapest improvements a digital product can get.

What is UX writing, and how does it differ from copywriting?

UX writing is text that helps the user complete a task. Copywriting is text that persuades a visitor to do something, such as contact you or buy. The two disciplines overlap, but the goals differ: copywriting creates interest, UX writing removes doubt. The same company needs both. The homepage and landing pages are copywriting, which we cover in a full guide to website copywriting. The form, the basket, order status emails and everything behind the login are UX writing.

Copywriting

  • Aims to spark interest and persuade
  • Read by visitors who haven’t decided yet
  • Headlines, sales copy, ads
  • Can have personality and length

UX writing

  • Aims to remove doubt and move the user on
  • Read by users in the middle of a task
  • Buttons, fields, errors, confirmations
  • Has to be short, precise and consistent
Two kinds of text, each with its own job.

Where does microcopy make the biggest difference?

  • Buttons and links: the point where the user decides to act.
  • Field labels and helper text in forms: especially at payment, sign-up and booking.
  • Error messages: the moment trust is either kept or lost.
  • Empty states: the first screen of a new system, an empty basket, a search with no results.
  • Confirmations and receipts: "What happens now?" is the question most people phone about.
  • Warnings before something irreversible: deleting, cancelling, paying.
  • Notifications, SMS and system emails: the text read outside the product.
  • Loading and waiting: a short explanation makes waiting easier to accept.

Start where the money or the frustration is greatest. In a webshop that is the basket and checkout. In a booking system it is the confirmation and the cancellation flow. In an internal system it is the errors staff most often email support about. Search your support inbox for phrases like "I can’t find" and "what does it mean", and you have a prioritised list of the copy to rewrite first.

How do you write button labels and error messages? Before and after

Typical copy we find in existing systems, and how it can be rewritten. The better version says what happens or what the user should do.

SituationBeforeAfter
Button in booking flowSubmitBook Tuesday at 10:00
Form errorInvalid inputEnter the phone number with 8 digits, e.g. 12345678
Server errorError 500We couldn’t save just now. Your details are kept, please try again in a moment.
Empty listNo dataYou have no orders yet. Create the first one and it will appear here.
DeletingAre you sure?Delete the customer Hansen ApS? All 14 orders are deleted too and cannot be restored.
ConfirmationThank you!Thanks, we’ve received your order. You’ll get an SMS when it ships.
Login errorLogin failedEmail or password doesn’t match. Forgot your password?
Search with no results0 resultsNo products match "drill 18v". Try a shorter word or browse all tools.

The pattern repeats: the better copy uses a verb, names the concrete object and says what happens next. "Book Tuesday at 10:00" tells the user exactly what the button does. Buttons should start with a verb and match the heading on the screen, so "Create invoice" in the heading is also "Create invoice" on the button. Avoid switching between "Save", "Update" and "Apply" for the same action in different parts of the system.

A recipe for error messages

1

What happened?

Say it in plain language, without error codes or technical terms.

2

Where?

Show the message next to the field to fix, and mark it clearly.

3

What do I do now?

Give a concrete action or an example of the right format.

4

Is my work saved?

Keep what was entered, and say so, so the user dares to try again.

Four questions a good error message answers. Not every error needs all four.

Error messages are also a requirement under accessibility rules. WCAG 2.1, the practical target under the Accessibility Act, requires among other things that errors are identified and described in text, that fields have labels or instructions, and that suggestions for correction are offered where possible. A red border around a field therefore falls short. The message has to be readable by a screen reader and understandable without colour.

Empty states are an invitation

The first time a new user logs in, most lists are empty. This is where many systems show "No data" and leave the user without direction. A good empty state does three things: it explains what will appear here, it offers one clear action to get started, and it sets the tone for the rest of the product. In a customer portal that might be "Your invoices will appear here as soon as the first one is sent" with a link to update payment details. Searches with no results should always suggest a way forward.

Which tone should you use in Danish: du, I or De?

Danish interfaces almost always use "du", the informal you, and it is the safest choice for consumers and staff alike. Danish is a direct language, and an informal, friendly tone comes across as respectful. "De", the formal you, feels old-fashioned in most contexts and should only be used if your audience expects it. "I", the plural you, makes sense when addressing a company as a whole, for example in a proposal or on a B2B website, but inside the product there is one person at the screen. The key is to pick one form and keep it everywhere, including emails and SMS.

  • Write actively: "We’ll send a code" rather than "A code will be sent".
  • Use everyday words: "buy" over "purchase", "edit" over "modify".
  • In Danish, skip needless English loanwords when a good Danish word exists, but use the word your users use themselves.
  • Format numbers and dates the way the market expects: 1.200 kr. and 14. marts in Danish, DKK 1,200 and 14 March in English.
  • Plan for space: Danish compound words such as "leveringsadresse" (delivery address) are long and have to fit on a phone screen.
  • Apologise only when it is your fault, and keep it short.

How do you create a simple tone and copy guide?

  1. Describe your tone in three words with an example of each, such as "friendly, precise, calm".
  2. Build a glossary of the 20–30 most important terms and the one word you use for each.
  3. Decide the form of address and how you write dates, numbers, prices and times.
  4. Write rules for buttons: verb first, three words maximum, same word as the heading.
  5. Create templates for error messages, confirmations and empty states.
  6. Collect before/after examples from your own product. They teach more than rules.
  7. Put the guide where designers and developers work, for example in your design system.

The copy guide naturally belongs in a design system alongside colours and components, so a button component also comes with a rule for its label. If you are unsure about the difference between a style guide and a design system, read our guide to design system vs style guide.

How do you test whether microcopy works?

The simplest test is to read the flow aloud to a colleague who doesn’t know it and ask what they think happens when they press each button. The next step is a proper usability test, where you note where people hesitate, reread or ask. On a live product you can measure form drop-off, errors per field and how many support requests concern the same thing. With enough traffic, an A/B test of a button label or a heading can give a clear answer. We have a guide to conversion rate optimisation if you want to test systematically.

Who should write microcopy, and what does it cost?

In small and medium-sized projects the UX designer usually writes the microcopy, ideally together with the person on your side who knows the customers best. Large products have dedicated UX writers or content designers. The cost is rarely a separate line: when copy is written alongside wireframes and prototypes, it is part of the design phase. Reviewing and rewriting an existing flow, such as checkout or sign-up, typically takes one to three days with a UX designer. At typical freelance rates of DKK 600–750 an hour that is about DKK 5,000–18,000, which is often recovered through fewer support calls alone.

At Ceptiv we write real copy into the design from the first wireframe, in Danish and English, and it goes straight into the code. It is part of our UX/UI design. If you want an existing flow reviewed, a UX audit is a good place to start, or you can get a fixed price within 24 hours.

Questions about UX writing and microcopy

What is the difference between UX writing and content design?
The terms are often used interchangeably. UX writing usually refers to the short text inside the interface itself: buttons, errors, helper text and notifications. Content design is a broader term that also covers which content should exist at all, how it is structured and in which format it is delivered, such as a table, a guide or a video. In smaller companies it is usually the same person doing both, often together with the UX designer. What matters most is that someone owns the words.
Should microcopy be written before or after the design?
At the same time. When text is written last, a button has already been drawn with room for one word, and the copy gets squeezed into the shape. When it is written first, the design is built around what the user actually needs to understand. Best practice is to write real copy directly into wireframes and prototypes in place of placeholder text. That way you can test the words together with the flow, and developers receive the final text as part of the handoff.
How do we handle microcopy in several languages?
Keep all text in language files in the code so it can be translated without touching the design, and give each string a short note on where it appears. Never translate button labels word for word: "Get started" and "Kom i gang" take up different space and sound different. Test the layout with the longest language, often German or Danish, so buttons and menus don’t break. Have a native speaker review the flow inside the actual product, beyond reviewing a spreadsheet.
Can we use AI to write microcopy?
AI is good at suggesting variants, shortening long text and checking that the tone is consistent. It simply doesn’t know your users, your product or the errors that actually occur in your system. Use it as a sparring partner: give it your tone guide, the context of the screen and the goal of the text, and ask for five suggestions. Choose and edit yourselves, and test the most important ones with real users. Error messages in particular need someone who knows what went wrong technically.
Does microcopy affect SEO?
Only slightly in a direct sense, because most microcopy sits behind a login or inside forms that search engines don’t read. Indirectly it matters more: clear buttons and understandable forms lead to more completed purchases and enquiries, and users who find what they are looking for come back. On public pages, link text, headings and button labels make it easier for both users and search engines to understand what a page is about. Descriptive link text is therefore good UX and good SEO at once.
How long can helper text under a field be?
Short enough to read at a glance, typically one line and rarely more than two. Helper text should answer the question the user would otherwise ask, such as which format a date needs, or why you are asking for a phone number. If you need more than two lines, the field is probably too complicated and should be split or given a sensible default. Place helper text above or below the field, never only as placeholder text inside it, because that disappears as soon as the user starts typing.

Want us to build it for you?

You get a fixed-price proposal within 24 hours.

Dennis Nielsen

Dennis Nielsen

Head of Operations, Ceptiv

Free consultation

One free hour of advice before you start.

Describe your project and I will contact you as soon as possible, so we can schedule a no-obligation meeting. You leave with practical advice on how to get your project off to a good start.

  • Free
  • 1 hour
  • No obligation