What should a contact form ask for?

A useful first-contact form collects enough information to start a conversation. It does not need to complete the entire sales interview. For each field, ask: would we be unable to respond meaningfully without this answer? If the answer is no, make it optional or save it for the follow-up.

For example, a small web studio could start with a reply email and a short project description. A name can help personalise the reply; a phone number is unnecessary if the visitor prefers email. A detailed budget breakdown belongs later unless it genuinely determines whether the business can handle the enquiry. These are design choices for an example business, not a universal field count.

Give every field a label that stays visible

Keep labels such as “Email address” above or beside their inputs. Placeholder text disappears during typing, so it should not carry the field’s identity. In HTML, connect a label element’s for attribute to the matching input’s id. This gives the control an accessible label rather than relying on visual proximity. See the W3C guidance on labelling controls.

Make required and optional fields clear before submission. If you use an asterisk, explain it. Put any format instructions beside the relevant field, and associate supporting text with the control using aria-describedby where appropriate. The W3C form instructions tutorial explains these relationships.

Turn vague questions into useful prompts

“Message” leaves a visitor to invent a brief. A more useful label might be “What would you like help with?” followed by: “Tell us what you need, whether you have an existing website, and any important deadline.” This gives direction without requiring a long answer.

For a first enquiry about a website, an illustrative field plan is:

  • Email address — required: the address where the business should reply.
  • Project description — required: a short explanation, with a helpful example outside the input.
  • Name — optional: how the visitor would like to be addressed.
  • Existing website — optional: useful context if there is already a site.

Review this plan with the person who actually answers enquiries. If they consistently need one missing fact, improve the prompt or add a justified field. Avoid collecting information simply because a template includes it.

Validate gently and explain how to fix errors

Native HTML features such as type="email" and required can catch common mistakes. An email-format check does not prove that an inbox exists. Browser validation also does not replace validation on the server. Avoid rejecting harmless formatting variations when the value can be understood safely. The W3C validation tutorial covers these distinctions.

Use specific error text: “Enter an email address, for example name@example.com” is more useful than “Invalid input.” Keep the visitor’s other answers when showing an error. Do not identify a problem through red colour alone; explain it in text. For multiple errors, a summary with links to the affected controls can help people find what needs attention. Follow the W3C guidance on form notifications.

Distinguish sending from successful receipt

A button click is not evidence that an enquiry reached the business. Design separate states for sending, confirmed receipt and failure. Display success only after the backend confirms acceptance. If delivery is queued, say the enquiry was received rather than promising that an email has already arrived.

A practical confirmation could say: “Thanks, we have received your enquiry.” Add a response timeframe only if the team can support it. On failure, retain the message and offer a retry or another contact route. Ask the developer to test a slow connection and a rejected server request, not only the successful path.

Check the whole journey before launch

  • Complete the form on a narrow phone screen and with enlarged text. Check for clipped instructions or controls.
  • Use only a keyboard. Confirm that every control is reachable and the focused element is visible.
  • Check labels, instructions and status messages with a screen reader.
  • Submit empty required fields and an incorrectly formatted email address; check that recovery is understandable.
  • Simulate a failed request and confirm that the draft is retained.
  • Send a clearly labelled test enquiry and verify that it reaches the intended inbox or record system.
  • Link to the relevant privacy information and keep message contents out of analytics events.

This checklist is a practical starting point, not a complete accessibility or security audit. Review the form again whenever its fields, delivery service or business process changes.

Apply the changes to your website

Contact forms connect interface decisions with backend behaviour. WebHolick’s UI/UX design and website development services cover those complementary parts of a project. If you are reviewing a whole site, use our website redesign checklist to place the form in the wider visitor journey, or tell us about your project.