Microcopy Library
The product's action
The twelve slots
Primary button Create a item Secondary button Cancel Field label Item Field helper text We use this to create a item on your behalf. Empty state title No items yet Empty state body When you create a item, it will appear here. Loading state Loading… Error message We could not create a item. Try again in a moment. Success message Item created. Destructive confirmation Delete this item? This cannot be undone. Link text Learn more about items Permission prompt Allow the product to create a item? You can change this later in settings.
Checks
No action given; every slot here is written around what the reader is trying to do.
No product name; the permission prompt and error copy are less specific without it.
Scope and limits
Each slot is drafted from the action you name, in the register you choose, so the copy is specific rather than generic: the button says what it does, the empty state says what will appear, and the error says what failed.
The drafts are starting points, not final copy. They cannot know your error cases, your permissions or your brand's exceptions, and the checks are published guidance rather than rules.
The microcopy library drafts the twelve interface slots every product writes and rewrites — button labels, labels and helpers, empty states, loading, errors, confirmations and links — in the register you choose.
What is Microcopy Library?
The microcopy library starts from the action rather than the words. You name the product, the thing being acted on and what the reader is trying to do — create a report, book a fitting, start a trial — and the library drafts the twelve slots that cause the most support tickets: the primary button, the secondary button, the field label and its helper text, the empty state title and body, the loading state, the error message, the success message, the destructive confirmation, the link text and the permission prompt.
The register is the second input. Neutral, friendly and formal each change the vocabulary and rhythm of the drafts without changing what they say: the friendly error suggests another go, the formal one offers the support route, the neutral one simply states what happened. Drafting all twelve in one register is what makes an interface feel written rather than assembled from three people's habits. The library returns the slots as labelled lines so the whole set can be compared at a glance.
The checks apply the published guidance. A button label past four words stops being a button and becomes a sentence; the reader scans rather than reads it. The word invalid is flagged because it tells the reader they are wrong rather than what the form needs. An exclamation mark is flagged because in a confirmation it is noise and in an error it is tone-deaf. A short list of interface jargon — leverage, utilize, seamless — is checked across the output and your own wording, because at a glance every unfamiliar word costs the glance.
The empty state is treated as a slot rather than an afterthought. It names what is absent and what will appear there once the reader acts, which is the difference between an interface that feels broken and one that feels ready. The permission prompt carries the same discipline: what is being asked, and how to change it later.
The error message is the slot worth the most attention. It says what failed, avoids blaming the reader, and offers the next step — try again, check the connection, contact support — in one or two sentences. The library drafts it from the action so the message names what the reader was doing, which is what makes an error actionable rather than merely apologetic.
What the library cannot do is know your error cases, your permissions or your brand's exceptions. The drafts are starting points for a voice that a product team then owns, and the checks are published guidance rather than rules. Copy the set into your design system and edit in place.
Audit the shipped interface against the set once it exists. Collected screenshots of empty states, errors and confirmations are usually more honest than the design file, and comparing them with the library shows which slots drifted. The drift is predictable: errors written under time pressure, empty states inherited from a template, buttons renamed by feature teams.
Keep the set short enough to remember. Twelve slots are the ones that repeat across an interface; a product with a hundred screens has a hundred sentences, and the library governs the shapes rather than the vocabulary alone. When a new slot appears — a survey prompt, an inline hint — draft it in the same register and add it to the set.
How to use Microcopy Library
- Name the product, the object and the action the reader is trying to take.
- Choose the register the interface is written in and keep it consistent.
- Read the twelve slots and edit the drafts into your product's own voice.
- Clear the checks: short button labels, no blaming wording, no jargon.
- Copy the set into the design system next to the components it labels.
When to use Microcopy Library vs related tools
Use the microcopy library when an interface is being built or audited and the copy has to be consistent: a first release, a settings screen that has grown by accretion, a design system that needs the twelve slots documented. It is most useful before engineering writes placeholder text that ships. The same voice shows up in the Email Template Library for the messages the interface sends and in the FAQ Generator for the questions the interface raises. When the product needs its public explanation written, the About Page Builder carries the longer version of the same claims.
Privacy & Security
This tool runs entirely in your browser — no data ever leaves your device. There is no server round-trip, no upload, no logging, and no account required. Your input is processed locally using client-side JavaScript and is never stored, transmitted, or accessible to anyone else. When you close the tab, everything disappears.