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
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.
| Situation | Before | After |
|---|---|---|
| Button in booking flow | Submit | Book Tuesday at 10:00 |
| Form error | Invalid input | Enter the phone number with 8 digits, e.g. 12345678 |
| Server error | Error 500 | We couldn’t save just now. Your details are kept, please try again in a moment. |
| Empty list | No data | You have no orders yet. Create the first one and it will appear here. |
| Deleting | Are you sure? | Delete the customer Hansen ApS? All 14 orders are deleted too and cannot be restored. |
| Confirmation | Thank you! | Thanks, we’ve received your order. You’ll get an SMS when it ships. |
| Login error | Login failed | Email or password doesn’t match. Forgot your password? |
| Search with no results | 0 results | No 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
What happened?
Say it in plain language, without error codes or technical terms.
Where?
Show the message next to the field to fix, and mark it clearly.
What do I do now?
Give a concrete action or an example of the right format.
Is my work saved?
Keep what was entered, and say so, so the user dares to try again.
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?
- Describe your tone in three words with an example of each, such as "friendly, precise, calm".
- Build a glossary of the 20–30 most important terms and the one word you use for each.
- Decide the form of address and how you write dates, numbers, prices and times.
- Write rules for buttons: verb first, three words maximum, same word as the heading.
- Create templates for error messages, confirmations and empty states.
- Collect before/after examples from your own product. They teach more than rules.
- 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?
Should microcopy be written before or after the design?
How do we handle microcopy in several languages?
Can we use AI to write microcopy?
Does microcopy affect SEO?
How long can helper text under a field be?
Want us to build it for you?
You get a fixed-price proposal within 24 hours.
