Checkout form design: which field stops buyers

Owners tab through fields they know, and the browser fills the rest. A buyer types a phone number one digit at a time, and a field that checks the number on every keystroke turns red after the third digit. The buyer reads that as wrong input and stops. A postcode box set to a numeric keypad blocks the letters some postcodes contain. None of this shows up when you test from your own saved account, and none of it throws an error for you to find.

• Each field's type matches what it holds: email, telephone, or a text box with a digit keypad only where digits alone are valid.
• Labels stay visible once the buyer starts typing, so nobody has to remember what the field asked for.
• Errors appear after the buyer leaves a field or presses Continue, not after each keystroke.
• Fields a country does not use are hidden, not left required with an empty list.
• The autofill attributes on the address, postcode and phone fields name what each field actually holds.

A region, state or county field is only as good as the country chosen before it. When the country comes last on the form, a buyer fills in a street, a town and a postcode, then picks a country, and the region list swaps under their hands. An empty required list is a dead end that looks like a bug. The tell is in the screenshot. A red region field with no options, after a country was chosen, points to the order of the fields rather than to anything the buyer typed.

Put the country at the top of the address block, and let it drive the rest. The buyer then sees the region options shrink or disappear before they type anything. Where a country has no region list at all, the field should not exist for that buyer. Where the list exists but is incomplete, use a plain text box instead of a dropdown that leaves out the buyer's town.

Checkout flow testing

A telephone field should open a number pad, and an email field should open a keyboard with the at sign on it. A postcode field that opens a digit-only pad cannot take a postcode with letters, and the buyer has no way to type one. A placeholder that vanishes when the buyer starts typing removes the only hint of what the field wants, so a buyer who forgot the format has to delete their input to find out. Keep the label above the field and the example text short.

Autofill depends on the attributes you set. If the postcode field carries the attribute for a phone number, a phone browser may fill it with the wrong value, and the form rejects the postcode with a message that never names the field. The visitor's own words in the report usually give this away, such as a thought that says the keyboard only had numbers, or that the form filled something in on its own.

An error on a half-typed phone number is a rule firing too early. The buyer has not finished, so the message tells them they are wrong about something they had not yet completed. Show the error when the buyer leaves the field or tries to continue, and make it name the field and the format it wants, such as digits only, with the country code or without it. A message that says invalid input and nothing else sends the buyer back to guess.

Look at where the stops cluster. Several visitors stopping on the same field, each for a different reason, points to a field that asks too much. One visitor stopping on a field, with a clear reason, points to that one field. You can ask any visitor a question after the run, such as which field stopped them and what they expected to see there.

Forms gain fields over time: a tax number, a delivery note, a company name. Each new field brings its own rule, and a rule that suits one country can reject the next country's address. Rerun the same visitors after each new field, on a preview address, and read the step where the field sits.