Review form friction before testing the button copy

Try to complete the form first

A team discussing whether a button should say Continue or Get started may be overlooking a more basic problem: the form does not clearly explain what a person must enter, or it loses their work when something goes wrong. Before testing persuasive wording, walk through the complete interaction. Find the places where a willing visitor cannot understand, complete or recover from the task.

This review is a practical investigation, not a promise of a conversion increase. Correcting an obvious defect can make a form work as intended, while the effect on business outcomes requires its own measurement. Keeping those claims separate helps the team choose the right next step. A reproducible error belongs in a repair task; an uncertain copy preference may belong in an experiment proposal.

Pick one form with a meaningful role in the journey. It might be an account registration, a quote request or a checkout address step. Record what a successful submission is supposed to do, including the confirmation shown to the visitor. That final state matters because a reassuring screen is only useful when the underlying request has actually been accepted.

Begin with the fields and their purpose

List every field and ask who uses the answer. A quote form may need a contact email and a description of the request, while a phone number may be optional. If the team cannot explain why a field is collected at that point, investigate whether it belongs later in the conversation. The goal is an appropriate request for information, not the smallest possible form regardless of the business need.

The W3C forms tutorial recommends clear labels, grouping, instructions and feedback, and advises asking for information needed to complete the process. Use that guidance to review the actual interaction. A field can be necessary and still be poorly explained. Conversely, a beautifully styled field can create needless work if no one uses its answer.

Check required and optional status before entering anything. The distinction should be understandable without guessing from a color or an unexplained symbol. If a field is optional, make sure the form really accepts it empty. If a field becomes required only after a particular choice, verify that the rule follows the active choice and does not block another path invisibly.

Read labels after the form contains data

Placeholder text often disappears as soon as someone types. That makes it a weak substitute for a persistent label, especially when a person returns to review several populated fields. Enter realistic sample values, move away from the form and come back. Can you still tell what each value represents? If two fields look similar, does the label explain the distinction?

Instructions should appear where they are needed. A password rule shown only after submission makes the visitor discover it through failure. A date format can be explained beside the field before entry. Keep instructions specific: stating which characters are accepted is more useful than saying that a value is invalid. Avoid asking users to infer a hidden technical constraint.

Use examples carefully. An example phone number can clarify formatting, but it should not look like a prefilled answer or imply that only one country's format is accepted when the service supports several. The review should compare the visible instruction with the validation behavior. A mismatch creates frustration even when each part looks reasonable in isolation.

Complete the journey with a keyboard

Start at the page and use the keyboard to reach the form. Check that focus is visible and moves through controls in a sensible order. For a group of radio options, verify that the group has a meaningful label and that the options can be selected using expected keyboard behavior. A visually attractive control is incomplete if someone cannot operate it reliably.

Open any conditional fields and switch back again. Hidden controls should not remain in the keyboard path or retain requirements that block submission. For example, an installation address should not remain required after a customer changes to store pickup. The form's visible state and its validation rules need to agree throughout the interaction.

Also check the submit action. Does the button remain reachable? Can a person tell when a request is being sent? If repeated submission is temporarily disabled, does the interface recover after an error? Write down the exact sequence when a control becomes stuck. A developer needs those steps more than a general report that the form feels difficult.

Use a phone as a separate review

A narrow browser window can reveal layout problems, but a real phone also changes how people enter data. Review keyboard types, autofill behavior and the space available around controls. An email field should support the expected email input behavior. A long select menu may be workable on a desktop while becoming awkward on a phone, depending on the task and platform.

Try the form with realistic content. A long company name or address can expose clipping that short sample values miss. Watch what happens when the on-screen keyboard appears: can the visitor see the active field and its instruction? Does the page scroll normally? A fixed banner should not cover the action the person needs to complete.

Check the confirmation and error states at the same width. Teams sometimes review only the empty form, even though feedback adds the longest text. A message that wraps naturally on a phone is easier to understand than one squeezed into a fixed-height box. The form should retain room for clear instructions after something goes wrong.

Make failure part of the test

Submit an empty form, an invalid email address and a value that violates a documented limit. Then correct one problem while leaving another in place. The feedback should identify what still needs attention and help the visitor reach it. The W3C guidance on user notifications describes errors that identify the affected field and explain how to recover.

A general message at the top can summarize the problem, but it should not force the person to inspect every field for an unexplained red outline. Field-level guidance and an accessible notification can work together. The exact implementation depends on the form, but the visitor should understand what happened and what to do next.

Test a server failure in a controlled environment as well. The form should retain entered values and offer a reasonable retry path. It should not redirect to a success page merely because the request was sent. If the backend has not confirmed acceptance, the interface needs to say that the submission could not be confirmed. This distinction protects the visitor from leaving with a false impression.

Write findings that another person can reproduce

For each issue, capture the page, device, browser, input and steps. Describe the observed behavior separately from the expected behavior. A finding such as “Email field is confusing” leaves too much interpretation to the implementer. A finding that the label disappears after entry and cannot be recovered while reviewing the completed form is specific enough to investigate.

Add a completion check. If an optional company field blocks submission, the check might be that a valid inquiry succeeds with that field empty and that the field remains visibly optional. If a server error clears the form, the check should include retaining all relevant values after a simulated rejection. The check makes it possible to verify the repair without reopening the whole review.

Prioritize with the people who own the process. A failure that prevents a valid submission may deserve immediate attention. A confusing instruction may need clarification from the business before implementation. A speculative wording change can be recorded separately. Keep the reasoning visible so the team understands why each item has its place in the queue.

Return to copy with a working baseline

After repairs, repeat the affected paths and confirm that the measurement still represents actual acceptance. A changed interface can alter event behavior, so the analytics definition deserves a brief check too. Preserve the review record and the verification result together. That history can save time when a later release touches the same component.

Now the team can consider a copy test with a clearer baseline. State the hypothesis in terms of the visitor's uncertainty and explain why the proposed wording might address it. The immediate next step today is simpler: choose one form, complete it with a keyboard and a phone, and write one reproducible finding with an explicit recovery check. The resulting task gives the team a clear place to start.