By the time someone reaches your enquiry form, the rest of the website has done its job. They have read enough, trusted enough and decided enough to start typing. The form is the last place you can lose them, and it is surprisingly good at it.
The problems are rarely dramatic. A field that asks for something they do not know yet. A label that disappears the moment they click. An error message that says something went wrong without saying what. Each one is small, and each one is a reason to close the tab and try the next business on the list.
The key idea
Every field is a question you are asking a stranger. Ask only what you need to reply well, label each question so it cannot be misread, and make mistakes easy to put right.
Every field has to earn its place
Forms grow. Someone wants to know where the enquiry came from, someone else wants the budget, and a year later a simple contact form has nine fields and a dropdown. The most useful public research on this comes from checkout forms rather than enquiry forms, but the pattern is the same. Baymard Institute found that the average checkout in 2024 contained 11.3 form fields, and that most sites need only 8.
The GOV.UK design system, which is built on years of testing with the public, puts the principle plainly: make sure you know why you are asking every question and only ask for information you really need. It is a good test to borrow. For each field on your form, write down what you will do with the answer before your first reply. If the honest answer is nothing, the field can go, or wait until the conversation has started.
In practice, most enquiry forms need a name, a way to reply, and a box for the message. A phone number is useful if you actually intend to call, and should be optional if you do not. Budget, company size and how they heard about you are all reasonable questions for the first call, and all good reasons to abandon a form.
One smaller point: ask for a name in a single field. Google’s form guidance on web.dev recommends a single name input unless you have a good reason to store the parts separately, which most small businesses do not.
Labels go outside the box, not inside it
Placeholder text, the grey hint inside an empty field, looks tidy in a design file and causes problems in real use. Nielsen Norman Group set out why: it disappears as soon as someone starts typing, so they cannot check what the field was asking for; it can look like an answer has already been filled in; and it is usually too faint to read comfortably, which hits people with low vision hardest.
The fix is a visible label above every field, with any hint as a short line beneath it. GOV.UK keeps hints to a single short sentence, and marks the fields people can skip with the word optional, rather than marking mandatory fields with asterisks. On a short enquiry form, where almost everything is required, that is also less cluttered.
Let the phone do the typing
A phone keyboard is where every form feels longest. Two details change that. The first is the field type: an email field should be marked as type="email" and a phone field as type="tel", so the phone offers the right keyboard. The second is the autocomplete attribute, which lets the browser fill in a name, email address and phone number it already knows. Both are covered in Google’s form best practices, and both are invisible until they are missing.
It is worth trying this yourself. Open your own contact page on your phone and fill it in with one thumb. If you have to switch keyboards to type an @ sign, or type your own email address out in full, your visitors are doing the same.
Error messages should say how to fix the problem
Every form rejects something eventually: a mistyped email address, a required field left empty. The accessibility standard is clear about what should happen next. WCAG 2.2 success criterion 3.3.3 says that if an input error is detected automatically and “suggestions for correction are known, then the suggestions are provided to the user”.
In plain terms, “Invalid input” is not good enough. “Enter an email address, like name@example.com” is. The message should sit next to the field it refers to, the rest of what they typed should still be there, and the page should not scroll them back to the top to find it.
Timing matters too. Google recommends validating inline, as people enter data, rather than listing every error after they press submit. A gentle check when someone leaves a field is helpful; flagging an email address as wrong while they are still typing it is not.
What happens after the button
The form is not finished when it submits. The confirmation screen should say that the message has arrived, what happens next, and roughly when. “Thanks, we will be in touch” leaves people wondering whether to send it again. “Thanks, Sam. We have your message and will reply by email before 5pm tomorrow” does not.
An automatic acknowledgement by email does the same job for anyone who closes the page straight away. We covered how to set that handover up, and what to do when it fails, in small automations that reduce everyday admin.
Spam protection belongs here as well. Some of it is necessary, but it should be aimed at bots, not at people. If your form asks visitors to solve a puzzle before it will send, check whether a quieter method that works in the background would do the same job.
Check your own form in ten minutes
Where to start
- List every field and write down what you will do with each answer before your first reply. Remove or make optional anything that has no answer.
- Check that every field has a visible label above it, not only placeholder text inside it.
- Look for asterisks. If most fields are required, mark the optional ones instead.
- Fill the form in on your phone with one thumb. Did the email and phone fields bring up the right keyboard? Did the browser offer to fill in your details?
- Submit it with a deliberately wrong email address. Does the message say what is wrong and how to fix it, next to the field, with everything else you typed still in place?
- Submit it properly. Does the confirmation say what happens next and when? Did an acknowledgement arrive?
The best enquiry form asks the fewest questions it can still reply to well.
Where this fits
Forms sit at the end of the path we described in why visitors leave, and how a clearer path changes that, and getting them right belongs in any web design or web development project. Once a form is working, it is worth measuring how many people start it and how many finish, which is the kind of question our analytics and reporting work is there to answer.
Not sure what your enquiry form should ask, or why people stop halfway through? Tell us how it works now and we can talk through what to change.
Sources
- Baymard Institute: checkout optimisation and the average number of form fields (2024)
- GOV.UK Design System: question pages
- Nielsen Norman Group: placeholders in form fields are harmful
- web.dev (Google): payment and address form best practices
- W3C: Understanding WCAG 2.2 success criterion 3.3.3, error suggestion
