Most teams obsess over the hero image. They spend a week picking colours, another iterating on illustrations, and twenty minutes on the button label. The button label is doing more work than the illustration.
Microcopy is the small text. Button labels, form field hints, error messages, empty states, the line under the email input that says "We'll never spam you." It's the writing nobody quite owns: not the copywriter, not the designer, not the engineer. Default templates fill the gap, and the page reads like every other page.
This is a guide to writing it better. Three places to focus, with patterns to use and patterns to drop.
Why microcopy carries weight
A user makes a dozen micro-decisions on the way to a conversion. Each one is a chance to leave. The hero image makes one of those decisions: stay or scroll. Microcopy makes most of the rest.
Specifically:
- The button label decides whether the click feels safe or risky.
- The form field hints decide whether the form feels like a chore or a transaction.
- The error message decides whether a stumble turns into a recovery or a bounce.
Pages have died on a bad error message more than they've died on a bad hero. The hero gets attention because it's loud. Microcopy gets attention from us because it's where the bleed actually happens.
1. Button labels
A button label is a promise. The user reads it and predicts what happens after the click. If the prediction is correct, they stay. If it's off by even a little, the trust drops.
Patterns that work:
Name the outcome, not the action. "Get my pricing" beats "Submit." "Start free trial" beats "Sign up." The outcome version tells the user what they'll have on the other side of the click. The action version just describes what they're about to do, which is what they already know.
Use first person where it fits. "Get my proposal" feels different from "Get a proposal." The first version implies ownership, which is what the user is hoping for after the click.
Match the click to the next page. If the button says "Start free trial" and the next page is a six-field form, the trust drops. Either change the button to "Tell us about your team" or change the form to one field. The mismatch is the problem.
Patterns to drop:
"Submit" is never the right answer. Replace it with whatever the form is actually for.
"Learn more" is a stall. Either the user already wants more, in which case give it to them now, or they don't, in which case the link won't help. Replace with something specific: "See the pricing," "Read the case study," "Watch the 90-second demo."
"Click here" — there's no charitable explanation for this in 2026.
2. Form labels and hints
Forms are where landing pages quietly haemorrhage conversions. The form looks fine in isolation. Each field is reasonable. But the cumulative effect of seven reasonable fields is a wall.
The label is the field name. The hint is the smaller text that explains it. Get both right and the form feels half its length.
Patterns that work:
The label should be a noun in the user's vocabulary. "Email" works. "Email address" works. "Email contact information" is corporate. Pick the version your user would say out loud.
The hint should answer the question the user is about to ask. "Why do you need this?" is the most common one. "We'll send the proposal here. We won't add you to any list." That's a hint that earns the field.
Use placeholder text for examples, not labels. The placeholder ("name@company.com") shows format. The label sits outside the field so it's still visible after typing. Combining them — the placeholder also serves as the label — is an accessibility regression and a UX regression. Don't do it.
Patterns to drop:
Asterisks for required fields without explanation. The whole form is required unless you say otherwise. If half the fields are optional, mark the optional ones, not the required.
"Telephone." Use "Phone."
Stacked errors at the top of the form on submit. Show errors inline, where the user can fix them. The top-of-form summary made sense in 1998 and stopped making sense the moment we had JavaScript.
3. Error messages
The user has made a mistake. They've mistyped an email, left a field empty, or hit submit too fast. The next message they see determines whether they stay or close the tab.
Patterns that work:
Tell them what's wrong and how to fix it, in that order, in one sentence. "Please enter a valid email address." is fine. "Something went wrong." is not.
Use the second person and be specific. "Your card was declined. Try a different card or contact your bank." beats "Transaction error." The second version makes the user feel watched by a vague machine. The first puts agency back in their hands.
Acknowledge stakes if they're high. If the user hit a checkout error, "Don't worry — your cart is saved. You can try again or use a different payment method." The "Don't worry" line is doing real emotional work. It costs nothing to write.
Patterns to drop:
Error codes shown to end users. The user doesn't care that it's a 422. If you must show a code for support reasons, hide it behind a "More details" toggle.
"Invalid input." This is a non-message. Tell them which input and why.
Generic "something went wrong" without retry guidance. If the user can retry, say so. If they can't, tell them what to do instead.
A walkthrough: rewriting one form
Here's a real form pattern we see often. Five fields, all default microcopy:
Name *
Email *
Company *
Phone
Message *
[Submit]The rewrite:
Your name
First name is fine.
Work email
We'll reply here within 24 hours.
Company
Just the name, no need for the legal entity.
Phone (optional)
Only if you'd rather we call than email.
What you're working on
A sentence or three is plenty.
[Start the conversation]Same fields. Different result. Three things changed:
- Labels are in plain language, not form-builder default.
- Each field has a hint that earns it. Empty fields without hints feel demanding. Fields with hints feel like a transaction.
- The button label names the outcome ("Start the conversation") instead of the action ("Submit").
In live tests on similar forms we've watched submission rates rise 20-30% from these changes alone. No layout work. No backend work. Just better microcopy.
A checklist before you ship
- No "Submit" button anywhere.
- Every form field has a one-sentence hint.
- Required fields aren't marked with asterisks; optional fields are marked "(optional)".
- Errors appear inline, in plain language, with a fix path.
- Empty states say what to do next, not just "Nothing here."
- The "We won't spam you" promise lives near the email field, not buried in the footer.
Microcopy is where a careful page differs from a careless one. Most teams underweight it because it's small and ungrand. The pages we ship treat it as part of the design, not an afterthought.
If you want a landing page where the microcopy gets the same attention as the hero, see how we work.