Most teams spend their design effort on headlines, photography and layout. Yet the moments where a visitor actually gives up are often tiny: a button that says "Submit" and leaves them unsure what happens next, a red message that says "Invalid input," or a blank screen in a new account with no hint of what to do. These small pieces of text are called microcopy, and they are easy to overlook because nobody owns them.

This checklist helps you find and fix them. It works for a company website, an online booking form or an internal business system. You do not need to be a writer; you need to read your own product the way a first-time visitor would.

Step 1: Collect every piece of small text

You cannot improve what you have not seen in one place. Before changing anything, gather the text into a single document or spreadsheet. Walk through your site or app and capture:

  • Button and link labels, including menus and calls to action
  • Form field labels, hints and placeholders
  • Error and validation messages
  • Empty states (screens with no data yet)
  • Success and confirmation messages
  • Loading, waiting and "coming soon" messages
  • Automatic emails and notifications, such as booking confirmations

Many of these are written by developers as placeholders during building and never revisited. Seeing them side by side usually reveals inconsistencies straight away: one page says "Kirim," another says "Submit," a third says "Send message."

Step 2: Settle voice and language first

Decide a few rules once so that every message follows them.

  • Language and register. If your audience is Indonesian, choose Bahasa Indonesia, English or a deliberate mix, and keep it consistent. Decide between formal ("Anda") and a friendlier tone, based on your customers rather than your own taste.
  • Tone under stress. A playful tone can suit a button, but it rarely suits a payment failure. Errors should be calm and plain.
  • Vocabulary. Pick one word for each concept and stick with it. If you call it "booking" in one place, do not call it "reservation" and "appointment" elsewhere.
  • Jargon. Remove internal terms and technical words your customer would never say.

Step 3: Review buttons and links

A button label is a promise about what happens next. Check each one against this list:

  • Does it start with a verb that describes the outcome, such as "Request a quote" or "Book a visit"?
  • Would it still make sense if read out of context, for example by a screen reader listing all links on the page?
  • Is it free of vague words like "Submit," "Click here" or "Learn more" where something more specific is possible?
  • Does the main action look and read different from secondary actions such as "Cancel"?
  • For anything irreversible, such as deleting a record, does the label say exactly what will be lost?

If you are also weighing which contact route to offer, our article on choosing between WhatsApp, a contact form and a booking widget can help you decide what these buttons should lead to.

Step 4: Review form labels and hints

Forms are where unclear wording costs the most, because the visitor is already close to acting.

  • Keep labels visible. Placeholder text disappears when someone starts typing, so do not use it as the only label.
  • Say why you ask. A short note beside a sensitive field, such as "We only use this to confirm your booking," removes hesitation.
  • Show the expected format. If a phone number or date must follow a pattern, show an example before the person gets it wrong.
  • Mark what is optional. Make it obvious which fields can be skipped.
  • Ask only what you need. Each extra field is another place to stop. If nobody on your team uses an answer, remove the question.

Step 5: Rewrite error messages

An error message appears at a bad moment, so it has one job: help the person recover quickly. Good messages usually answer three questions in plain words.

What happened?

State the problem without blame. "This email address looks incomplete" is better than "You entered an invalid email."

Why, if it helps?

Only add a reason when it changes what the person does. "This time slot was just taken" explains why they need to choose again.

What should they do now?

Give the next step: a corrected example, a button to try again, or another way to reach you if the problem is on your side.

Tip: Replace every "Invalid input" with the exact fix, for example "Enter a mobile number starting with 08 or +62." If the message cannot say what to change, the validation rule is probably too vague.

Also check these points:

  • Is the message placed next to the field it refers to, not only at the top of the page?
  • Does the form keep what the person already typed after an error?
  • Is the problem shown with more than colour alone, such as an icon or text, so it is noticeable for everyone?
  • For system failures, does the message say that it is not the user's fault and offer a way forward, such as saving their work or contacting support?

Step 6: Design useful empty states

An empty state appears when there is nothing to show yet: a new dashboard, an empty cart, a search with no results. Treating it as an afterthought leaves people staring at a blank page. A good empty state does three things:

  • Explains what belongs here. "Your orders will appear here once you place one."
  • Offers the obvious next action. A clear button such as "Browse products" or "Add your first customer."
  • Distinguishes between types of emptiness. A first-time empty screen, a filtered list with no matches and a failed data load each need different wording.

For search with no results, suggest what to try: check the spelling, remove a filter, or contact you. This matters particularly in business systems used by staff who are not technical, where an empty table can look like a broken system.

Step 7: Check confirmations, loading and success messages

  • After a form is sent, does the confirmation say what happens next and roughly when the person can expect a reply? Avoid promising a time you cannot keep.
  • Does it repeat key details, such as the date and service they booked?
  • Do loading states tell people something is happening, especially on slower mobile connections?
  • After a destructive action, can the person undo it or at least see what was changed?
  • Do automatic emails match the tone and terms used on the website?

Step 8: Test the words with real readers

You are too familiar with your own product to judge it. Try these simple checks:

  1. Read it aloud. If it sounds like a manual or a legal notice, simplify it.
  2. Ask someone unfamiliar to complete a task while you stay quiet. Note every moment they hesitate or ask what a word means.
  3. Trigger the errors on purpose. Leave fields blank, enter odd formats and go offline. Most teams never see their own error messages until a customer does.
  4. Check on a phone. Long messages that fit on a desktop can push important buttons off the screen.
  5. Ask your support or sales team which questions customers ask repeatedly. Each one points to missing or unclear text.

For a broader review beyond wording, see our practical UI/UX review checklist.

Takeaways

  • Collect all small text in one place before you edit anything.
  • Agree on language, tone and vocabulary so the product sounds like one voice.
  • Make buttons describe outcomes, and keep form labels visible.
  • Write errors that say what happened and exactly how to fix it.
  • Give every empty state an explanation and a next step.
  • Test by triggering errors and watching real people, not by rereading your own text.

None of this requires a redesign; much of it can be changed in an afternoon and improves every visit afterwards. If you would like a second pair of eyes on your site or system, our team works on this through UI/UX design, and you are welcome to get in touch.

Frequently asked questions

Who should own microcopy in a company?

Ideally one person is responsible for consistency, whether that is a marketer, a product owner or a designer, while developers and support staff contribute. The key is that someone reviews the text as a whole, rather than leaving it to whoever builds each screen.

Is microcopy only relevant for websites with forms or apps?

No. Even a simple company website has buttons, a contact form, a confirmation message and possibly a search or a 404 page. All of these are microcopy, and they affect whether a visitor takes the next step.

How often should we review our error messages and empty states?

Review them whenever you add a feature, change a process or notice repeated support questions, and do a full pass once a year. Business rules change over time, and old messages can quietly become wrong.