Contact and Quote Forms That People Finish

Why form details matter

Nielsen Norman Group (NN/g) summarises the case in its top 10 recommendations for website forms (2016). It cites a 2014 academic study in which forms that followed basic usability guidelines were completed faster, and 78% of submissions were error-free on the first try, against 42% for forms that broke the guidelines.

Keeping forms short, using real labels instead of placeholder text and putting a form on every service page are covered in our guides to landing pages and B2B lead generation. This guide goes into the form itself.

Decide which fields earn their place

NN/g's first recommendation is to keep it short, and it gives a practical test. Remove fields that collect information that can be "(a) derived in some other way, (b) collected more conveniently at a later date, or (c) simply omitted." Applied to a typical enquiry form:

• Usually needed: name, an email or phone number to reply to, and a message box for what they need.
• Often derivable: the service they are asking about, if the form sits on that service page and records which page it was sent from.
• Better later: company size, full address and how they heard about you can usually wait for the first call.

For each field left, write down who uses the answer and what for. If nobody does, take it out. Fewer fields also means less personal data to protect; see our privacy basics guide.

Mark required and optional fields

NN/g's article on marking required fields (2019) is direct: "mark all the required fields". A line at the top saying "All fields are required" does not do the job, because "people don't read instructions at the top of forms". People who cannot tell will guess, deciding "they don't really need my phone number", and then meet an error.

The asterisk is familiar on the web and takes little space. NN/g warns against pale grey or low-contrast asterisks, which are an accessibility problem for low-vision users. Marking optional fields as "optional" as well is, in its words, "a nice perk". Keep optional fields to one or two. In the HTML, use the required attribute, so screen readers announce it too.

Layout, labels and formats

From NN/g's top 10:

• One column. "Multiple columns interrupt the vertical momentum of moving down the form." Short, related fields such as city and postcode can share a row.
• Labels close to their fields, directly above the field on phones and short forms.
• Radio buttons for two or three choices instead of a drop-down.
• Formats explained before, not after. If a field needs a format, "state the exact instructions", and better still, accept the common formats yourself.
• No Reset or Clear button. "The risk of accidental deletion outweighs the unlikely need to 'start over'."

The W3C's WCAG 2.2 makes labels a requirement in success criterion 3.3.2, Labels or Instructions (Level A): "Labels or instructions are provided when content requires user input." Use the right input type as well. MDN's page on telephone inputs says type="tel" "causes mobile browsers to display a special keyboard for entering phone numbers". MDN also notes that phone numbers are not checked for a format automatically, "because formats for telephone numbers vary so much around the world", so do not reject a number just because it has spaces or a country code.

Error messages people can fix

WCAG 2.2 sets two rules. Success criterion 3.3.1, Error Identification (Level A), says that if an error is detected, "the item that is in error is identified and the error is described to the user in text". The W3C adds that after a failed submission "it is not sufficient to only re-display the form without providing any hint that the submission failed." Success criterion 3.3.3, Error Suggestion (Level AA), asks you to say how to fix it when you know. The W3C's own example: "Email is not valid" passes the first rule, while "Please provide a valid email address in the format [email protected]" passes both.

NN/g's guidelines for reporting errors in forms (reviewed 2024) turn this into design rules:

• Put the message next to the field, so people can read it while they fix it.
• Do not show an error before the person has finished typing in that field.
• Use more than colour: an icon and text as well as red, which also helps colour-blind users.
• A summary at the top is fine, but not as the only sign of an error, and not in hover tooltips.
• Keep what the person typed, so they correct it instead of starting again.

When the server finds the errors, the W3C forms tutorial on user notifications suggests saying so in the page title and main heading, for example "3 Errors – Billing Address", and moving focus to the first field with an error. Checks in the browser are for convenience; the server must still check everything, as our guide to stopping form spam explains.

Let the browser fill it in

Browsers can fill in a person's name, email, phone and address from what they have saved, if the form tells them what each field is. MDN's reference for the autocomplete attribute lists the standard values, including:

• name for a full name. MDN notes that a single name field "is generally preferred" because it "avoids dealing with the wide diversity of human names".
• email and tel for contact details.
• organization for a company name.
• street-address, postal-code and related values for addresses.

MDN advises against autocomplete="off", since "it removes a feature that many users depend on", and against made-up values, which stop the browser from matching the field. Valid values also meet WCAG 2.2 success criterion 1.3.5, Identify Input Purpose (Level AA).

Longer quote forms and repeated details

A quote form for a complex job may need more than a few fields. Then split it into short steps, and let people go back without losing what they entered. WCAG 2.2 added success criterion 3.3.7, Redundant Entry (Level A): information a person already entered in the same process must be "auto-populated, or available for the user to select" when it is needed again, with a few exceptions such as security. The W3C notes that browser autofill alone "is not considered sufficient"; the site itself must carry the details forward. A "same as billing address" checkbox is the familiar example.

If a quote depends on files such as plans or photos, say which formats and sizes are accepted next to the upload field, not in an error afterwards. Job application forms have their own rules on what to ask; see our guide to careers pages.

After they press send

The W3C tutorial says "success messages are also important to confirm task completion", and its examples put the confirmation in both the page title and the main heading. A good confirmation page or message says:

• that the enquiry was received;
• who will reply, how, and roughly when, in terms you can keep;
• what to do if it is urgent, such as a phone number;

A confirmation email with a copy of what they sent gives people a record and shows the address works. Check your own notification emails arrive too; our SPF, DKIM and DMARC guide covers why they sometimes land in spam. If enquiries go into a CRM, see our guide to connecting your website to a CRM.

A checklist

• Every field has a named person who uses the answer.
• Required fields are marked on each field; optional ones say "optional".
• One column, visible labels, sensible widths and no Reset button.
• Errors appear next to the field, in text, with how to fix them, and entries are kept.
• Fields use the right input types and standard autocomplete values.
• Multi-step forms keep earlier answers and never ask twice.
• The confirmation says what happens next, and an email copy arrives.
• You have sent a test enquiry on a phone and on a desktop.

Frequently asked questions

How many fields should a contact form have?

As few as you need to reply well. Nielsen Norman Group advises removing any field whose answer can be found another way, collected later or left out.

Should I mark required fields or optional fields?

Mark every required field, for example with an asterisk in a clear colour. Nielsen Norman Group found that a note at the top saying all fields are required is often missed or forgotten.

Where should form error messages appear?

Next to the field with the problem, in text, saying what is wrong and how to fix it. WCAG 2.2 requires errors to be identified and described in text, and to suggest a fix when one is known.

Should I turn off autocomplete on my forms?

Usually not. MDN advises against autocomplete="off" because many people rely on autofill. Use the standard values such as name, email, tel and organization.

What should happen after someone sends a form?

Show a clear confirmation that the enquiry arrived, who will reply and roughly when, and what to do if it is urgent. A confirmation email with a copy of the message is a useful record.

Planning a new website? Our builds include contact and quote forms tested end to end, with spam protection, so enquiries land in your inbox and not in a spam folder, and we check speed, forms and accessibility before the site goes live. See our website development service and all our services, or email [email protected].