Microcopy Guidelines
Set one standard for how the app writes buttons, hints, confirmations, and errors.
What it adds
A written standard for the app's short-form text — labels, helper text, confirmations, errors, and recovery instructions — applied to the strings already in the product.
What your agent is told to do
5
What your agent is told to do
5-
1
Collect the app's existing short strings by type: button labels, field labels and hints, empty states, success confirmations, error messages, and permission refusals. Write the guideline from what is already there, then fix the strings that disagree with it.
-
2
Require every action label to name its action and object rather than a generic verb. A dialog offering OK and Cancel forces the user to reconstruct what they asked for; one offering Delete invoice and Keep it does not.
-
3
Make every error say what happened, whether the user's data is safe, and what to do next. An error that only names a failure leaves the user with no move.
-
4
Write failures as a statement of the situation rather than an accusation. The user did not break anything by leaving a required field empty, and copy that says otherwise gets read as scolding.
-
5
Do not write copy that only fits in English at desktop width. Allow for text that grows by a third or more when translated, and do not size a button to its current label.
Edge cases it handles
7
Edge cases it handles
7- Generic labels — OK, Submit, Yes, Continue — are ambiguous in a dialog and meaningless when read out of context by a screen reader. Every label must work when read alone.
- The same concept must use the same word in every string. If the interface calls it a workspace in navigation and a team in an error, the user assumes they are two different things.
- Blame language turns a recoverable state into a reprimand. Say what is required, not what the user failed to do.
- Translated strings routinely expand well beyond the English length, so layouts must tolerate longer labels without truncating a button or wrapping a single word onto its own line.
- Text that will be interpolated must not be assembled from sentence fragments; a sentence split across variables cannot be translated or pluralised correctly.
- Copy must not name internal services, error codes, or ticket references in a message meant for a customer, though a reference identifier for support is fine when it is labelled as one.
- Which word the app uses for each concept is owned by Terminology Dictionary; this guideline governs the shape of the sentence around those words.
Definition of done
8
Definition of done
8- Every action label names its verb and its object, and reads correctly in isolation.
- Error messages state the cause, the state of the user's data, and the next step.
- No user-facing string assigns fault to the user.
- Layouts hold without truncation when strings grow by a third.
- Interpolated messages are complete sentences with variables, not concatenated fragments.
- Product terms in copy match the Terminology Dictionary exactly.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Feedback Widget
Feedback Widget
Let anyone report a bug or send a comment from the page they are looking at.
What it does
An always-available launcher that opens a short feedback form and submits it with page context attached.
How it works
- 1 Put a single persistent launcher in one corner of the app and open a compact form in place. Do not route the user to a separate feedback page and lose the context they were about to describe.
- 2 Attach the current URL, the app version, the viewport size, the signed-in account, and a short trail of recent client errors automatically, so the reporter does not have to describe where they were.
- 3 Show the captured context to the user before they send it, in a collapsible section, and let them remove it. Silent collection of screen state is a trust problem.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/feedback-widget
Booking Page
Booking Page
A shareable page where someone picks an open time and confirms it in a few clicks.
What it does
A public scheduling page listing open slots, taking a booking, and confirming it to both sides.
How it works
- 1 Build the visitor path first: pick a date, see open times in their own zone, fill a short form, confirm, and receive an email with the details and a cancellation link. That is the minimum coherent version.
- 2 Derive open slots from the owner's availability rules and existing bookings on the server at request time. Do not trust a slot list the browser has been holding since page load.
- 3 Reuse the app's existing Time Zone-Aware Scheduling for conversion and storage, store every time as an absolute instant, and display it converted to the visitor's detected zone with the zone named on screen.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/booking-page
Date and Time Display Component
Date and Time Display Component
Render every date and time through one component so none of them are ambiguous.
What it does
A single shared way of displaying dates and times, covering absolute format, time zone, and optional relative phrasing.
How it works
- 1 Find every place the app renders a date or a time — tables, activity feeds, audit logs, exports, emails, tooltips — and route them all through one display path rather than formatting at each call site.
- 2 Never render an all-numeric date whose day and month could be swapped. Spell or abbreviate the month, or use an unambiguous ordering consistently, because a reader has no way to tell 04/07 from 07/04.
- 3 State the time zone whenever the value is a specific moment rather than a calendar day, and be explicit about whose zone it is — the viewer's, the record's, or the account's — rather than leaving it implied.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/date-and-time-display-component
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.