Your quote form works. Can a customer finish it on a phone?

By Noe Guerrero III

A quote form can accept submissions and still be frustrating to finish on a phone. To review it, work through every field, decide why it belongs there, and deliberately make one mistake. The goal is a request your team can act on without making the customer do unnecessary work.

A smaller version of the desktop page isn't enough. You need to see what happens with the keyboard open, a long answer entered, and an attachment the customer doesn't have ready.

Start with the first conversation your team needs

Before changing the design, ask whoever answers inquiries: “What information lets you take the next useful step?”

For some businesses, that means routing the request to the right person. For others, it means deciding whether an on-site visit is needed. A preliminary inquiry doesn't always contain enough information to produce a final price, and the form should make that clear.

Here's a hypothetical McAllen sign shop. The owner wants enough detail to start a conversation about a storefront sign, without asking a customer to prepare a production-ready order from a parking lot.

These are decisions for this example, not a universal field count. A detailed technical estimate may need more information. Keep a field when its answer changes what your team does next; otherwise consider making it optional or asking later.

Mark optional fields plainly. Don't let customers discover the required ones only after pressing the button.

Read the labels after you've typed

Open the form on a phone and enter something in every field. Can you still tell what each answer means?

W3C's labeling guidance explains how labels should identify and connect to their controls. A properly associated label also gives people a larger area to activate the field. Labels above fields can help on narrow screens, but their placement still needs a layout review.

Keep the label visible while someone types. Put a short example or explanation beside a question that needs one: “Approximate width and height, if known” is more useful than making the customer guess which measurement you want.

Then check the practical details. Does a chat bubble cover the last field? Does a sticky banner hide the submit button? Can you review a long project description without losing your place? Record the specific obstruction, including the phone and browser you used.

Check typing assistance one field at a time

Tap the email field, then the phone field. See whether the keyboard helps with the expected answer. Try autofill, and check where the saved information lands.

MDN's input reference distinguishes input types, keyboard hints through inputmode, and autofill hints through autocomplete. Supporting browsers can offer email or telephone keyboards. These aids don't establish that the submitted information is valid.

Give your developer an observation: “The phone field opens a general text keyboard on this device,” or “Autofill puts my name in the company field.” That's a clearer repair request than “Make the form more mobile friendly.”

For the sign-shop example, also type a name with an accent and a size description such as “about 6 feet wide.” If the business wants approximate dimensions, the field should either accept that answer or explain the specific format it needs before submission.

Make one mistake and recover

Use an agreed test procedure or a test environment so the review doesn't create real orders or unnecessary staff alerts. Fill out the form, leave one required answer blank, and try to continue.

GOV.UK's validation guidance recommends retaining entered answers and showing useful errors near the affected fields, with an error summary. The customer should be able to find and correct the problem without retyping the whole request.

For your review, write down what actually happens:

• Can you locate the missing answer without hunting through the page?

• Does the message explain the correction the form expects?

• Does the project description remain intact?

• After correction, can you continue normally?

“Enter an email address that includes @” describes a correction. A delivery-service outage needs different wording; it isn't a mistake in the customer's email address. Have your developer test that failure separately without disrupting the live service.

Try the upload and read the final message

If there's an attachment field, try it with a harmless test file of an allowed type. Check that the accepted formats and size limit are visible before selection. Cancel the file picker once, too. An optional attachment shouldn't silently become a condition for continuing.

Finally, read the confirmation as a customer. GOV.UK's confirmation-page guidance calls for a clear next step, timing, contact details, and a reference number where one exists. For a quote request, describe what was received and what the team will do next. Only state a response timeframe your business can meet.

Ask staff to verify the test request in the system they actually use. A browser message by itself doesn't prove an email arrived or a person reviewed it. If you also need to connect inquiries with campaigns, use our separate lead-source tracking guide.

Hand over a short repair list

You don't need a long presentation. For each issue, record the field, the observed behavior, the requested change, and the result after retesting. Attach a screenshot when it makes the problem easier to reproduce, keeping real customer information out of it.

Prioritize anything that blocks completion or loses an answer. Then work on unnecessary questions and unclear instructions. Repeat the same task after the repair so you can tell whether the original problem is resolved.

For businesses serving the Rio Grande Valley in English and Spanish, repeat the review in each supported language. Our bilingual forms checklist covers that language handoff in more detail. If the form needs development work, our website and software services can help you define the changes and the checks that demonstrate they're finished.