Microcopy is the small language around an interface: button labels, field hints, confirmation messages and errors. It is easy to treat these words as decoration, but they often decide whether someone understands what will happen next. Good microcopy answers a practical question at the moment it arises, without making a promise the product cannot keep.

Make buttons describe the outcome

A button should name the action or the next state. “Send enquiry” is clearer than “Submit” when a person is asking about a service; “Save changes” is more informative than “OK” in an editing screen. Avoid labels such as “Click here,” which describe a mouse gesture rather than the result and become vague on touch devices or when read aloud.

Use a consistent verb for the same action throughout a site. If one page says “Book a visit” and another says “Schedule an appointment,” users may wonder whether these are different processes. Keep the label short, but do not shorten it so far that the meaning disappears. On a destructive action, name the consequence: “Delete draft” is safer than “Continue.” If the choice is irreversible, pair the button with a clear confirmation step rather than relying on a dramatic color alone.

Help people complete forms

Start with labels that remain visible after a person begins typing. Placeholder text is useful for a brief example, not as the only label: it disappears and can be difficult to read. Ask only for information the task needs. For each field, explain an unusual format before submission—such as whether a phone number should include a country code—rather than surprising someone with an error later.

Make required fields obvious and explain why sensitive details are requested. A hint such as “We use this number to confirm your appointment” is more useful than “Phone.” If an optional field is truly optional, say so; otherwise people may waste time guessing. Keep instructions beside the relevant input, and use plain language instead of internal terms like “customer ID” when the visitor would recognize “account number.”

Treat errors as part of the conversation

An error should say what needs attention and how to fix it. “Enter a valid email address, such as name@example.com” gives a next step; “Invalid input” does not. Preserve any information the person already entered, move focus to the first problem when appropriate, and identify the field in text as well as color. After a successful action, confirm what happened and what comes next, such as when to expect a response, only if that timing is known.

Review the words in context

Read each screen aloud, test it on a narrow display, and ask a first-time visitor what they expect each button to do. Watch where people hesitate; a short usability session can reveal unclear terms better than a long debate in a meeting. Change one confusing phrase at a time and check whether task completion improves without adding pressure or false urgency. For more interface-writing examples, browse the MGTech Labs blog; MGTech Labs is another reference point when comparing web resources.

The goal is not clever copy. It is a small, reliable promise: the person can tell what to do, what information is needed, and what will happen after the action.