How to Write Microcopy in UI

Most advice on how to write microcopy in UI hands you adjectives. Be clear. Be concise. Sound human. That is true and it is nearly useless the moment you are looking at an empty button with a 20 character ceiling and a checkout that has to feel trustworthy. This guide is the version with the strings in it: the seven copy types you actually write, four tones for each, and a character count on every line.

Microcopy is the small functional text inside a product. The button you press, the error you hit, the empty screen before there is any data to show, the one line under a form field. It is not the headline on the marketing site. It is the words that do a job while someone is trying to finish a task, which is why a UX writer and a copywriter approach it differently. If that split matters to you, we pull it apart in UX writing vs copywriting.

Here is the part a normal guide cannot give you. Every example below was generated with MicroKopy's own prompt builders, the same ones behind MicroKopy's generator, then parsed and counted. Nobody wrote them by hand and they did not come from another product's screenshots. Read them as a fast first draft you would edit rather than a finished answer, and read them for the shape: real output, real length, four tones you can hold up next to each other.

The seven types, four tones, every character counted

MicroKopy generates seven copy types. Each block below is one type at four tone presets: professional, friendly, playful, and minimal. The number after each line is its character count, spaces included. Watch how little the meaning moves while the wording swings, and how the count moves with it.

Buttons and CTAs

A button label has the least room and the most weight. It is the last thing read before an action, so it should name the action or the outcome, never the mechanism. For the longer argument and more contexts, see the CTA button copy guide.

Error messages

An error arrives when someone is already annoyed. Say what happened, say it without blame, and give the next step. The same card decline reads very differently across tones, and the playful register is the one to handle with care here. There is a full framework in writing better error messages.

Empty states

An empty state is the first screen a new user sees before they have done anything. It is prime space to explain what will appear and to offer one clear action. Below, the three parts (a heading, a line of body, a button) are separated by slashes and the count is for the whole string. More on the design side in empty state copy.

Tooltips

A tooltip only shows when asked, so it should answer one question and stop. Even playful products keep tooltips functional, because the reader is in "what does this do?" mode, not "entertain me" mode. There is a longer piece on tooltip UX writing.

Form labels

Labels are where tone almost disappears. Look at the professional, friendly, and minimal rows: for a work email field they land on the same handful of words. Only the playful preset reaches for personality, and it pays for that with characters. Worth knowing before you brief a writer to make your forms sound warmer.

Confirmations

A confirmation reports what just happened, above all when it cannot be undone. Naming the blast radius ("all 40 files") is the difference between reassurance and a shrug.

Notifications

A push notification has two fields with two jobs. The title identifies and signals, the body gives the reason to tap. Both have their own ceiling, so both get a count. If you write these often, there is a whole guide to push notification copy.

What changes across tones, and what does not

Read down the tone columns and a pattern shows up. On a button or a form label, tone barely registers, because the space is too small to carry it. On an error, an empty state, or a notification, tone has room to change the feel of the whole message. That is the practical rule: spend your tone budget where there are characters to spend it, and keep the tightest slots plain.

One more thing the raw output taught us. The generator occasionally reached for a long dash to join two clauses, which is one of the clearest signals that a machine wrote a line. Those were edited out here by hand, which is exactly the kind of pass generated copy still needs. For a wider set of patterns pulled from shipping products, see our microcopy examples.

Why the character count is on every line

Length is not a style preference, it is a constraint the layout imposes. A primary button holds a few words before it wraps or clips. A push notification title is cut by the operating system somewhere around thirty characters, and the reader never sees the rest. A tooltip that runs three sentences means the interface failed to explain itself and copy is covering for it.

Writing to a known ceiling changes the work. Instead of writing a line and hoping it fits, you set the number first and choose among options that already respect it. That is why every example here carries its count, and why the counts are the detail practitioners actually ask for.

The three things most guides skip

Screen readers

A screen reader announces the text, not the picture. An icon-only button with no label is a silent button. The fix is an aria-label that reads like the microcopy would if it were visible: "Delete project", not "trash icon". Error messages need to be announced the moment they appear, through an assertive live region or role="alert", or a blind user keeps fixing a form they cannot tell is broken. A label that lives only as placeholder text vanishes the instant someone types, and it was never read aloud to begin with. The accessibility notes in form validation copy go deeper on the field-level version of this.

Localisation

English is one of the shorter languages you will ship in. The same string is often noticeably longer in German or Finnish, so a button that fits at home can wrap or truncate once translated. A character ceiling set in English gives your translators a target instead of a surprise. Two habits matter most. Leave room, so a snug English line has somewhere to grow. And never build a sentence out of concatenated fragments, because word order is not universal and the pieces will reassemble into nonsense. The generated notifications above use whole strings with placeholders like [file_name] and [days_left] for exactly this reason: the variable slots in, the sentence stays intact.

Testing your copy

You can catch most copy problems before a build. Read the line aloud; if you stumble, the user will too. Render it at the real width with the longest realistic value, so [sender_name] becomes a genuinely long name and not "Sam". Run one screen-reader pass over the flow. Where you have the traffic for it, an A/B test settles arguments that taste cannot, though it carries a real cost: version B ships to real people, so never test something that could cost a user money or data. Most of the time the character count catches the overflow long before any of that.

A pre-ship checklist

• Name the action or the outcome, not the mechanism behind it.
• Know the ceiling before you write, then write to it.
• Say what happens next, above all after an error or a delete.
• Make the label mean something on its own, so a screen reader can use it.
• Check the longest realistic value, then translate and check the width again.

Where to start

Pick the one screen where users hesitate most and rewrite its copy against this list. You will usually find a button that hides its outcome, an error that blames the reader, or an empty state that says nothing. If you would rather start from options than a blank field, MicroKopy will generate all seven types to a character ceiling you set, and the demo runs without an account. Either way the goal is the same: words that do their job and get out of the way.