The Mobile Form Looks Fine—Until a Customer Tries to Finish It

Start with the information you actually need

Every additional field creates another opportunity for confusion. Decide what is necessary to answer the first enquiry and what can wait until a later conversation. A tutor may need a contact route, language level, and preferred lesson time, but not a home address at the first step. Avoid collecting sensitive information simply because a template includes the field.

Keep the initial observation separate from the proposed solution. Write down what was known before making the change, which part of the exercise is hypothetical, and which information must come from the real website owner. This prevents an attractive explanation from becoming an unsupported claim. Ask a second reader to identify the decision being made and the condition that would change it.

Use visible labels

A placeholder disappears when someone starts typing and is a poor substitute for a persistent label. Keep the purpose of each field visible, associate labels with controls, and explain any unusual format before the user encounters an error. Group related choices logically. A form should remain understandable when someone returns to a partially completed screen.

Use a comparison that another authorised person could repeat. Keep the relevant conditions stable, record the version or document reviewed, and change only what the question requires. If a comparison cannot isolate the cause, describe it as an observation rather than a proof. The useful record explains what was checked, what remained outside the test, and what should be investigated next.

Choose sensible input behaviour

A phone keyboard should help with the information requested. Use suitable input types and autocomplete where appropriate, but do not make validation so strict that genuine addresses or names are rejected. Consider international telephone formats and names with spaces or accents. Formatting preferences should not become unexplained barriers to contacting the business.

Make the verification artefact small enough to review carefully. A short note, a safe test submission, or a documented configuration comparison can be more useful than a large unexplained report. Keep private information out of public examples. When the evidence is incomplete, state the gap beside the decision instead of allowing a confident summary to conceal the unresolved part of the work.

Make errors recoverable

An error message should identify the problem and explain what to do next. Keep valid answers after a failed attempt. Place feedback where the visitor can find it and make focus movement understandable. A red border alone does not communicate enough. Test mistakes deliberately rather than assuming the happy path represents the entire experience.

Before accepting this step, consider the ordinary failure path as well as the successful one. Identify who notices a problem, what the visitor sees, and how the team returns to a known state. A process that works only when every assumption is correct remains fragile. The recovery action should be understandable to someone who did not design the original change.

Keep the submit action reachable

A sticky banner, floating chat bubble, or on-screen keyboard can obscure a button. Check the page at ordinary phone widths and with enlarged text. Give controls enough spacing to avoid accidental activation and ensure the visitor can scroll to the final action. The correct layout is the one people can use under realistic conditions.

Check the result in the context where it will actually be used. An isolated editor view, a demonstration account, or an unusually fast device may hide a difficulty that matters in normal operation. Record any conditions that differ from the intended audience. This does not require pretending to test every possible situation; it requires a clear account of the situations that were and were not examined.

Verify delivery beyond the success message

A friendly confirmation does not prove an enquiry reached the responsible person. Send a non-sensitive test message, inspect the receiving inbox, and document any expected delay. Explain the next step to visitors without promising a response time the organisation cannot meet. If delivery fails, the team needs a route to investigate rather than repeatedly asking customers to try again.

Give the decision an owner and a review trigger. The person approving a change should know what evidence supports it and what would justify reopening it. Keep the handover practical: describe the action, the expected observation, and the limit of the conclusion. If responsibility is shared, explain where the next step goes rather than leaving it somewhere between several people.

Provide an alternative contact route

Some visitors cannot complete a particular form or prefer a different channel. Offer a real email link or another published route and describe what information is useful. Do not make the alternative harder to find than the form. An email link should be recognisable as an email action, especially on a shared device without a configured mail app.

Avoid turning a useful local finding into a universal rule. A result can depend on content, configuration, staffing, timing, or the audience’s needs. Note those dependencies in the review. A good recommendation remains conditional where the evidence is conditional, and it distinguishes a sensible next experiment from a result that has already been established by a controlled observation.

Review the form after each dependency change

Themes, plugins, spam controls, and email settings can change form behaviour. Include the enquiry task in release checks instead of reviewing only page appearance. Track repeated user problems as categories rather than collecting unnecessary personal details. The maintenance record should show what changed and which task was checked afterward.

Finish this check with a record another maintainer can understand later. Include the reason for the decision and any unfinished action, not just a mark saying complete. Revisit the check when its assumptions change. Keeping that link between a decision and its evidence makes future updates easier and prevents an old instruction from surviving after the situation it described has disappeared.

Worked example: a fictional scenario with concrete decisions

For the fictional tutor, start with the journey of a parent seeking an evening lesson. The parent has a phone, an email address, and a short question about availability. The original form asks for a postal address, age, current employer, preferred course, phone number, email, and a long explanation. The tutor cannot explain why several of those fields are required before the first reply. Removing unnecessary fields is a scope decision based on the enquiry process, not an experiment promising a universal increase in conversions.

The revised form asks for a name, a reliable contact route, the course of interest, and a message. Persistent labels explain each field. A note asks visitors not to include sensitive personal details. The confirmation describes the actual next step rather than promising an immediate response. An email link appears nearby for people who cannot use the form. The tutor checks that the published address is monitored and that someone else knows how to respond during an absence.

The first test intentionally omits the contact information. The page should identify that field, explain what is required, and preserve the valid message. The tester then enters a name containing an accent and a phone number in an international format if a telephone option remains available. These are ordinary possibilities, not unusual edge cases to be excluded without reason. A form that rejects legitimate information creates work for both the visitor and the organisation receiving the enquiry.

The second test uses a narrow screen and enlarged text. The tester opens the phone keyboard, reaches the submit button, and checks whether a floating widget covers it. The exercise also follows the alternative email link. If the device has no mail application configured, the visible address should still be understandable and copyable. Each observation is written as a task result rather than as a claim that the page is accessible to every person in every situation.

Finally, trace a fictional submission through the success message and receiving mailbox. Record what arrives, who can see it, and what happens if delivery fails. The tutor then adds this short test to the maintenance routine whenever the theme, form plugin, spam controls, or mail configuration changes. The outcome is a more understandable process with evidence of its checked steps. A measured effect on enquiries would require a separate observation period and appropriately collected data; the exercise itself does not supply that result.