Design a contact form that genuinely helps

Start with enquiries and how they are handled

Group common requests: questions, quotations, support and proposals. Decide what information is essential to route each one and what can be requested in the reply. A mandatory budget field, for example, may exclude someone still trying to define the scope; its purpose should be clear.

Explain who will receive the enquiry and what the sender can expect next. Promise a response time only when the team can meet it. If messages go to different departments, define the routing internally instead of expecting visitors to know your organisation.

• Purpose of each enquiry type.
• Essential fields and the reason for collecting them.
• Person responsible for reading and responding.

Make entry understandable and recoverable

Give every control a visible label, mark required fields and provide examples only when helpful. Placeholder-only instructions disappear during entry. MDN’s form guidance explains labels and grouping.

Test with a keyboard, on a phone and with longer text. When entry fails, explain the issue near the field, keep values already entered and provide a clear way to correct it. Also test a lost connection and a repeated submission. Success feedback should confirm the action without exposing personal data.

Limit data and explain its use

Collect what is useful for the enquiry and explain the purpose, relevant recipients and where to learn more about processing. For French operations, CNIL guidance recommends information at collection, with a short first layer near the form and a privacy-page link where appropriate. Adapt the notice to the actual processing and applicable law.

Avoid requiring sensitive documents or an account for a simple question. If attachments are necessary, explain accepted formats, size and retention. Check that spam controls do not prevent legitimate enquiries.

• Current collection notice.
• Only necessary data and attachments.
• Accessible alternative contact route.

Test the journey through to a reply

Send test enquiries with an empty field, malformed address, long message and valid input. Check the screen feedback, arrival in the correct place, readability of the received message and the team’s ability to reply. A confirmation page alone does not prove delivery.

After launch, check the full route regularly, especially after changing hosting, mail delivery or spam protection. The prelaunch checklist places this test among the wider release checks.

Separate input, selection and confirmed submission

For suggested values, check displayed text and submitted identifier after selecting and then editing. A town field must not retain the previous suggestion’s reference accidentally. Secondary commands such as attaching a document remain distinct from submission.

Follow waiting, failure and success. “Received” requires actual service confirmation. Preserve recoverable input after failure; when the result is uncertain, explain verification instead of encouraging blind repetition.

Choose interface links, buttons and actions · Design autocomplete for selecting a value · Write and announce interface status messages