How to use UX writing to reduce form abandonment

A prospect read the service page, compared the offer with two alternatives and decided to request a call. The form has seven fields, one of them asking for annual revenue, and a button labeled "Submit." Nothing explains why revenue matters, who will read the message or when a reply will come. The tab closes.

In the analytics report, that visit shows up as an engaged session with no conversion. For anyone accountable for demand generation, it costs twice: the company paid to bring that person to the page, and the lead never reached sales. One of the possible explanations is the interface text, which is exactly where UX writing comes in.

In this article, you'll learn how to tell whether the problem really lies in the copy, which parts of the form deserve a review, what a good rewrite looks like, with before-and-after examples, and how to assess whether the change paid off.

Why do visitors reach the form and not submit it?

On a B2B website, the contact form is usually filled out by someone who is still evaluating vendors. Submitting their details is a small commitment, but a real one: they share their name, job title and company with a sales team they don't know yet. Before clicking, they weigh that cost, and every unanswered question makes the decision harder.

Four questions account for much of this friction:

• What is this form for? A block titled "Contact us" doesn't say whether the person will request a quote, schedule a call or receive a resource. Without that information, visitors can't tell whether they're in the right place.

• Why do they need this information? Revenue, headcount or a cell phone number feel intrusive when they appear without context. The hesitation doesn't come from the effort of typing. It comes from uncertainty about how the information will be used.

• What did I do wrong? A message like "Invalid field" signals that something is wrong without saying what or how to fix it. If the error repeats, the visitor starts guessing the expected format.

• What happens after I submit? Without knowing who will respond, through which channel and how soon, the person clicks with no idea of the outcome. For someone who has to bring a vendor shortlist to their manager by Friday, response time matters as much as the proposal.

None of these questions, on its own, proves that the problem is the writing. A form with flawless labels will still lose leads when the page attracts the wrong audience, when the button doesn't respond on mobile or when the offer isn't convincing. Copy enters the diagnosis as one hypothesis among several.

What is UX writing and how does it affect conversion?

UX writing is the practice of writing the text that is part of the interface: field labels, buttons, instructions, error messages, confirmations and notices. This text guides people as they use the site, tells them what is expected at each step and helps prevent or correct errors.

The term microcopy is often used as a synonym. The difference is one of scale: microcopy is the individual piece, such as the line below a field, while UX writing is the discipline that decides what each piece says, where it appears and how it relates to the others.

How does UX writing fit into design and development?

In many companies, form copy falls between teams. Marketing writes the page, design lays out the fields and development implements validation, but no one owns the sentence that appears when the email address is wrong. The result is the default text from the component library, usually generic or awkwardly translated.

UX writing closes that gap by treating text, interface and code as parts of the same project, starting at the wireframe. To see how research, data and interface design come together in a single process, read what a UX consultancy does.

“In prototypes, the form almost always appears in two states: empty and filled in. The states that matter most for conversion sit in between, like a mistyped email address, a failed submission and the confirmation screen. When we design those moments with the final copy, we find out early whether the message fits the layout and whether the button says what will happen.” - Rafael Andrighetti, Head of Design at Dexa

How can you tell whether abandonment comes from the copy, the design or the functionality?

Before approving a rewrite, leadership needs to know where the drop-off happens. The form is the last step of a conversion funnel, and problems from earlier stages tend to surface there. A page that attracts informational searches brings in visitors with no intention of requesting a quote, and no amount of microcopy will change that.

A specialized team usually starts with Google Analytics 4. The tool records two useful events: form_start, when someone first interacts with the form in a session, and form_submit, when they submit it, according to Google's documentation. Comparing the two separates people who never started from people who started and gave up, two situations with different causes.

These numbers need to be checked, because forms from third-party tools may require specific setup. To find out which field people get stuck on, the team sets up field-level error events without recording what was typed, since Google prohibits collecting personally identifiable information.

Data shows where the drop-off happens, and usability testing shows why. Watching people from the target audience fill out the form while thinking aloud reveals doubts no report captures, such as hesitating at the revenue field.

The number of fields is also part of the analysis. Each new field costs the visitor time and a decision, and some information can wait until the first call. Cutting fields and rewriting copy are different interventions, and applying both at once makes it impossible to know which one worked.

Which parts of the form copy should you review?

When the diagnosis points to the filling-out stage, the review starts with an inventory of the form's copy. Each element has a job, and problems usually appear when one element tries to do another's job.

Why shouldn't a placeholder replace the label?

A placeholder is the gray text inside a field that disappears when the person starts typing. Used as a label, it forces visitors to remember what each field asked for. The W3C forms tutorial points to two more problems: screen readers don't treat placeholders as labels, and browsers often display them with contrast below the recommended minimum recomendado.

For the business, the impact is twofold. The form loses leads and fails success criterion 3.3.2 of WCAG 2.2, the W3C accessibility guidelines, which requires labels or instructions whenever content requires user input. The fix is simple: a visible label outside the field, with the placeholder reserved for an example such as "name@company.com".

Why explain the purpose of each field?

Qualification fields, such as job title, company size or expected budget, help sales prepare for the first call. Without an explanation, visitors read them as screening. A line of help text changes that reading: "We use this to connect you with someone on our team who has experience in your industry."

The Brazilian federal government's form simplification guide, published on gov.br, takes the same approach. It recommends explaining why each piece of information is needed.

The GDPR, the European Union's data protection regulation, reinforces this reasoning. Its Article 5 sets out principles such as purpose limitation, data minimization and transparency: personal data must be collected for specified purposes and limited to what is necessary. In the United States, California's CCPA follows the same logic and requires the collection and use of personal information to be reasonably necessary and proportionate to the purposes for which it was collected. Legal review of the form belongs to the company's legal team or data protection officer.

How do you write more helpful instructions and error messages?

A good review starts by preventing errors. If the ZIP code field accepts only numbers, the instruction says so before the person types. If the phone field requires an area code, an example shows the format. Revealing the rule only after submission forces people to make a mistake to find out what was expected.

When an error does happen, the message has two jobs: explain what went wrong and say how to fix it. The GOV.UK Design System, the UK government's interface standard, tested across public services, recommends showing the message next to the field and keeping everything the person entered, including the correct answers.

The same guide also lists what gets in the way. Words like "valid" and "invalid" add nothing, technical jargon doesn't help anyone fix the problem, and a generic message like "Field required" doesn't tell people what to do next. Another useful guideline is to repeat the words from the label in the message, so people can connect the error to the right field.

Error message examples: before and after

The last example shows that sometimes the best error message is the one the system never displays, because the code accepts common format variations.

Related reading: Brand tone of voice: how to build recognizable, consistent language

How can copy clarify what happens after submission?

Uncertainty about the next step weighs most on the final click, and the button is the first place to address it. As the gov.br guide recommends, buttons with descriptive labels, such as "Request a proposal" and "Schedule a call," say what happens after the click, while "Submit" says nothing about the outcome.

Right below the button, a short line can say who will respond, through which channel and how soon. The confirmation page or message closes the loop: it confirms the request arrived, explains what happens next and, when it makes sense, suggests how the person can prepare for the conversation.

Before: "Thank you! Your message was sent successfully."

After: "We've received your request. Someone from our [team] team will read your message and reply by email within [actual sales response time]. To make the most of the call, have your current website address and the project's main goal at hand."

The details in brackets are a management decision, not a copywriting one. Response time, channel and owner must match the sales team's actual process. If the team replies within two business days, promising a response within 24 hours trades uncertainty for frustration, and that frustration shows up in the very first contact.

How do you measure whether the UX writing review improved the form?

A review can only be proven with comparable numbers. Before making any change, the team records a baseline for the metrics over a few weeks, separating desktop from mobile and, if possible, breaking it down by traffic source. The logic is the same as connecting UX metrics to business goals: each number answers a question leadership is asking.

• Start rate: sessions with form_start divided by page sessions. Shows whether the form invites people to fill it out.

• Completion rate: submissions divided by starts. This is the metric most closely tied to labels, instructions, errors and the button.

• Errors per field: how often each validation fires. The GOV.UK Design System recommends tracking this frequency to revise copy and test variations.

• Lead quality: the share of submissions that sales considers a fit for the ideal customer profile.

When traffic volume allows, A/B testing is the most reliable approach: part of the traffic sees the current version and part sees the revised one over the same period, which neutralizes seasonality and campaigns. B2B forms often receive few submissions per month, so a test can take a long time to reach a reliable result. In those cases, a before-and-after comparison works, as long as the periods are equivalent and nothing else changes on the page.

Submission volume alone doesn't tell you whether the review worked. A form that does a better job of explaining who the service is for may receive fewer leads and generate more real opportunities.

Where should you start reviewing your form?

There's a test any manager can run in a few minutes: fill out your own form on a phone, as a visitor would, making the most likely mistakes. An email without the @, a phone number with parentheses, a required field left blank. Every moment of doubt becomes a hypothesis for the diagnosis.

When the investigation spans copy, design, development and data at the same time, it helps to have those disciplines in the same project. At Dexa, Experience Design, Enterprise Technology and Digital Growth are part of the same team, so a copy hypothesis can be tested without losing sight of the CRM integration or the traffic source.

Frequently asked questions about UX writing in forms