Usually because of the words around the fields, not the fields themselves. Microcopy is the small text on buttons, labels, hints, and errors. It answers the quiet questions a visitor has at the exact moment they hesitate. When it is missing, they fill the gap with suspicion and leave.
We get asked to redesign forms that do not need redesigning. The layout is fine. What is missing is a sentence explaining why you want a phone number, or a button that says what happens when it is pressed. Those are ten word fixes that behave like layout changes.
Microcopy is the cheapest conversion work available. It requires no new design, no development sprint, and no approval from anyone who owns the brand guidelines.
Microcopy is the small functional text that helps someone use an interface. Button labels, field labels, helper text under inputs, empty states, confirmation messages, error messages, and the reassuring line next to a submit button. It is writing that does a job rather than writing that sells.
The distinction from marketing copy matters. Marketing copy persuades someone to want the thing. Microcopy helps someone who already wants it get it done. Mixing the two is why so many buttons say something clever and nothing useful.
It is called micro because each piece is tiny, not because the effect is. A single word change on a submit button can shift completion rates, because it changes what the visitor believes will happen next.
Almost every piece of microcopy answers one of three questions. What is this for? What happens if I do it? What went wrong? If your interface leaves any of those unanswered at a decision point, that is where you are losing people.
Because people do not read pages, they scan them, and microcopy is what they land on. Nielsen Norman Group's foundational research from 1997 found that "79 percent of our test users always scanned any new page they came across; only 16 percent read word-by-word." The words next to the action are often the only words that get read.
That same Nielsen Norman Group study measured what better writing was worth. Concise text produced a 58% improvement in measured usability, a scannable layout produced 47%, and objective rather than promotional language produced 27%. A version combining all three was "124% better usability" than the promotional control.
Those figures are decades old, so treat them as directional rather than as a forecast for your site. The underlying finding is the durable part. Writing that is short, scannable, and free of exaggeration measurably outperforms writing that is not.
Nielsen Norman Group also explains the mechanism, noting that "promotional language imposes a cognitive burden" because users have to filter out exaggeration to find the facts. Every promotional adjective near a button is a small tax on the person trying to press it.
It names the outcome, not the mechanism. "Get the proposal" tells someone what they receive. "Submit" tells them what the server does. Buttons written from the visitor's point of view consistently feel safer to press, because the person knows what they are agreeing to.
Specificity also sets expectations, which prevents the worst outcome of all: a click that surprises someone. "Book a call" and "Send us a message" lead to completely different next screens, and a visitor who expected one and got the other feels tricked even though nothing dishonest happened.
Keep the verb first and cut everything decorative. Two or three words is usually enough. Long button labels get truncated on mobile and read as instructions rather than actions.
The one place to spend extra words is directly beneath the button, where a short reassurance line can remove the last objection. Something as plain as "No obligation, we reply within two working days" does more than most redesigns. We go further into this in our guide to designing a call to action that converts.
Label every field plainly, and explain anything that could feel intrusive. A label says what to type. Helper text says why you need it or what format you expect. Fields that ask for something personal without explanation are the ones people stall on.
This is an accessibility requirement, not only a preference. The W3C's WCAG 2.2 success criterion 3.3.2, at conformance Level A, states that "labels or instructions are provided when content requires user input." Its stated intent is to present "instructions or labels that identify the controls in a form so that users know what input data is expected."
The specification is explicit that this covers everything, not just mandatory fields. It clarifies that the word requires "is used here as a synonym for 'accepts', 'expects', or 'allows'" and that "the criterion applies to all form fields, whether they're required or optional."
Helper text should appear before someone types, not after they get it wrong. Telling a visitor the password rules once they have already failed is the most common avoidable frustration in web forms. We cover the wider pattern in our guide to designing forms people actually finish.
No. Placeholder text disappears the moment someone starts typing, which removes the label exactly when it is needed for checking work. It also fails people using screen readers and anyone who gets interrupted halfway through filling a field.
The pattern persists because it looks clean in a design file. A form with floating grey text inside every box photographs beautifully and performs poorly. This is one of the clearest cases where visual tidiness and usability genuinely conflict, and usability should win.
If the visual weight of labels bothers you, the answer is typography, not deletion. Smaller, lighter labels above the field keep the information permanent while staying quiet. The label still exists when the visitor looks back at what they typed.
Placeholders are useful for one thing, which is showing an example format. A date field can helpfully show what shape of input it expects. That is an addition to a label, never a replacement for one, and it fits the broader accessibility work we describe in our WCAG accessibility guide.
Say what happened, in plain words, and say how to fix it. Nielsen Norman Group is direct that "merely stating the problem is also not enough; offer some potential remedies." An error message without a remedy is just bad news delivered efficiently.
Do not blame the person. Nielsen Norman Group advises against "phrasing that blames users or implies they are doing something wrong, such as invalid, illegal, or incorrect." Those words appear in default framework messages everywhere, which is why so many forms accidentally sound hostile.
Be specific about what failed. Nielsen Norman Group notes that "generic messages such as An error occurred lack context" and recommends providing "descriptions of the exact problems to help users understand what happened." A visitor who cannot tell which field is wrong will usually just leave.
Write for the reader, not the system. The guidance is to use "legible and readable text" and to "avoid technical jargon and use language familiar to your users instead." Nobody outside your team knows what a validation exception is, and nobody should have to.
Empty states, loading states, and success messages. These get skipped because they are not in the main flow of the design file, yet every visitor hits at least one of them. A blank screen with no explanation reads as a broken site.
Empty states are an opportunity rather than a gap. The first time someone opens a dashboard, a search result page, or a saved list, there is nothing there. That is the perfect moment to explain what will appear and how to make it appear.
Success messages get written carelessly because the hard part is over. But the moment after someone submits is when they most want confirmation that it worked, what happens next, and roughly when. A message that just says "Thanks" leaves all three unanswered.
Loading and waiting text matters on slower connections. A spinner alone tells someone nothing about whether to wait. A short line naming what is happening turns an anxious pause into a tolerable one.
Whoever understands the visitor best, working alongside whoever built the interface. In practice this means it should be written during design rather than filled in at the end. Microcopy written after the layout is locked always fits the space rather than the need.
We write it in the browser with the real interface in front of us, because the words and the layout affect each other. A label that reads perfectly in a document can be far too long once it sits beside a narrow input on a phone.
Involve whoever answers customer emails. They know the actual questions people ask before they buy, in the actual words people use. That is the raw material for good microcopy, and it is usually sitting unread in a support inbox.
Keep a single document of your interface wording so it stays consistent. When one form says "Get started", another says "Sign up", and a third says "Create account" for the same action, visitors slow down trying to work out whether these are different things.
Go to your most important form and read only the small text. Check that every field has a permanent label, that anything personal is explained, that the button names the outcome, and that your error messages tell someone how to fix the problem. That pass takes under an hour and usually finds three real problems.
Then submit the form yourself and read what happens next. Most teams have never seen their own confirmation message, and it is frequently the weakest writing on the entire site.
If you want a second pair of eyes on the wording around your key actions, we are happy to walk through it with you. It is the fastest improvement available on most sites. Reach out through phoenix.studio and point us at the page.
Tell us where you want to go. We'll tell you how we'd get you there.