Website form usability is the design of labels, fields, validation, and confirmation so people can submit accurate information without guessing. Most enquiry forms fail by asking for too much, hiding the labels, or reporting “invalid input” with no hint.
A form is part of the page’s job. If the navigation led someone to “request a quotation,” the form should continue that sentence.
Labels, order, and required fields
- Put a visible label above each field. Placeholder text inside the box disappears as people type and is a poor label.
- Ask for the minimum that the next human step needs. Name, a way to reply, and the request are often enough for a first enquiry. Department, budget, and fax can wait.
- Mark required fields in text (“required”), not with colour alone.
- Group related items: contact details, then the request. A long single column beats a clever two-column form on a phone.
- Use the right control: a date picker for a date, a short list for states you actually serve, free text when you do not know the options.
Autocomplete attributes (name, email, tel) help browsers fill known values. They do not replace labels.
Validation and errors
Validate when it helps, not as a puzzle.
- Check format after the person leaves the field or on submit, not on the first keystroke of an email address.
- Put the error next to the field and summarise at the top if several failed.
- Say what to do: “Enter a mobile number including the leading 0” is better than “Invalid.”
- Do not clear the whole form when one field fails.
- Keep the submit button available. Disabling it with no explanation looks like a broken page.
Server-side checks still matter. Browser checks can be skipped. Both should return the same plain-language messages.
From empty form to a trustworthy submission
- Show labels and only the fields you will use
- Let the visitor complete the form without interruption
- On errors, keep their answers and explain the fix
- Confirm success on the page, not only by email
- Store the enquiry where someone is responsible for a reply
Mobile and success
On a narrow viewport the keyboard covers the bottom of the screen. The active field and its error must scroll into view. Input types such as email and tel bring a more suitable keypad. Tap targets for the submit button need space. Width behaviour is discussed in responsive breakpoints.
After a successful submit, replace the form or show a confirmation that states what was received and when someone will respond. A silent refresh looks like a failure, so people submit twice.
Keyboard use, focus, and labelled controls are accessibility basics. See website accessibility.
A practical example
An enquiry form requires company registration number, ten dropdowns, and a message, then shows a red border on “phone” with no text. The revision asks for name, mobile, email, and message, labels each box, and on a bad mobile number says to use digits starting with 0. Success text reads: “We have your enquiry and will reply on a business day.” The extra qualification questions move to the follow-up call.
Key takeaways
- Visible labels and fewer fields reduce errors before validation does.
- Error text must explain the correction and preserve answers.
- Confirm success on the page.
- Check the form on a phone with the keyboard open.
FAQ
Should we use multi-step forms?
Use more than one step when the form is genuinely long and later questions depend on earlier answers. A three-field enquiry does not need a wizard.
Is CAPTCHA required?
Use a check that blocks abuse without blocking customers. A puzzle that fails on a phone will cost enquiries. Monitor spam before adding friction.
Where should submissions go?
To a named inbox or CRM queue that someone checks. A form that only writes to an unattended mailbox is a layout, not a process.