A form that gets finished asks only for what you need to respond, labels every field clearly, checks input in a helpful way and explains errors in plain words. Each extra field is another decision for the visitor, so the best first step is to remove fields rather than redesign them. The rest of this guide covers what to ask, how to label it and how to handle mistakes.
Start by cutting
For each field, ask one question: could we reply to this enquiry without it? If yes, delete it, or ask it later, in the reply or on a call.
A typical enquiry form might need:
- A name
- An email address (or phone, if you genuinely prefer to call)
- A message
Everything else needs a reason. Fields such as company size, budget or “how did you hear about us” may help you triage, but each one costs you some completions. Be honest about that trade-off, and keep optional questions clearly optional. There is no universal ideal number of fields, so treat any specific number as a hypothesis to test on your own traffic.
Label fields properly
Every input needs a visible label that is programmatically connected to it. W3C’s guidance on labels or instructions says users should know what kind of value a field expects, and that expected formats should be stated when they are unusual. The same guidance warns against clutter: enough guidance to avoid confusion, not a wall of text.
Practical rules:
- Put the label above the field, not only as placeholder text that disappears on typing.
- Mark optional fields as optional rather than starring every required one.
- Use plain wording that matches how people describe the thing.
- Group related fields, such as a set of radio buttons, with a clear group label.
web.dev’s forms course also notes that tools like Lighthouse warn when a label is not connected to its control and flag missing autocomplete attributes, and that automated tools cannot detect every issue, so testing with real people still matters (web.dev).
Help the browser and the thumb
Use the right input types
Choosing type="email" or type="tel" gives browsers a chance to validate and present a suitable keyboard. MDN explains that the inputmode attribute hints at the kind of data expected so a device can show an appropriate virtual keyboard, such as numeric, telephone or email layouts, but that it does not enforce validity (MDN). Use real input types for validation and inputmode when you need a keyboard hint on its own.
Allow autofill
Add appropriate autocomplete values for name, email and phone so a visitor can fill the form in a tap. Make fields wide enough for the content and keep tap targets comfortable.
Test on a phone
Fill your own form on a real phone, on a patchy connection, with one thumb. Many problems appear only there.
Validation and error messages
W3C’s guidance on error identification requires that when an input error is detected, the field in error is identified and the error described in text. Colour alone is not enough. Redisplaying the form with no text explaining the failure does not meet the requirement.
The GOV.UK Design System gives useful, specific advice on writing error messages:
- Say what went wrong and how to fix it.
- Be specific: avoid “An error occurred” or “This field is required”.
- Reuse the wording of the field label so the message connects to the field.
- Keep the tone positive and avoid blame or filler such as “you forgot” or “oops”.
- Use identical wording beside the field and in any summary at the top.
- Keep what the user has typed rather than clearing the form.
An example: instead of “Invalid input”, write “Enter an email address in the format name@example.com”.
Validate when it helps, usually when a field is left or on submit, rather than flagging a mistake while someone is still typing.
After submission
Confirm what happens next on the page: that the message was received and what the visitor can expect. Do not promise a response time you cannot meet. If a form feeds an automated follow-up, review that it reads well; see AI automation for business operations.
Checklist
- Every field justified by a real need
- Visible labels connected to inputs
- Optional fields marked
- Correct input types and autocomplete values
- Specific, text-based error messages in plain language
- Entered data preserved on error
- Tested on a phone
- Clear confirmation after sending
Forms are one part of the larger conversion picture in what makes a business website convert, and the wording on the submit button is covered in microcopy and button labels.
Where Radiance Impact fits
Radiance Impact’s Digital Technology & AI Solutions division builds business websites, landing pages and workflow automation, including the forms and follow-up behind them. To talk through yours, get in touch.
Sources
- Understanding SC 3.3.2: Labels or Instructions, W3C
- Understanding SC 3.3.1: Error Identification, W3C
- Error message, GOV.UK Design System
- inputmode global attribute, MDN Web Docs
- Learn Forms, web.dev
