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.

Prepare a small acceptance matrix with five situations: valid submission, missing required field, invalid address, network interruption and retry after waiting. For each, record device, action, displayed message, retained values and the state received by the team. Use a test identifier and fictional details so the report does not copy personal contact data.

An error message must explain what to correct and let the person continue. Colour alone does not provide that instruction. The W3C WAI tutorial on form notifications explains how to associate errors with fields and make feedback understandable. Also test a double click: it should not cause the team to process the same enquiry twice.

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

Reduce repeated typing while retaining clear labels and validation.

Synthetic case: a contact form distinguishes name, email and phone. Use suitable tokens and try both a saved test profile and manual input. Autofill can produce unexpected values, so validate fields on the server too. Avoid arbitrarily disabling an aid that people rely on.

Fictional example: a registration has a main contact and a different participant. Two email fields do not necessarily request the same value. The groups section-contact email and section-participant email identify separate sets; the section- token comes first. This hint helps autofill without guaranteeing every browser’s behaviour.

Choose the field’s meaning too: name denotes a full name, organization an organisation. Keep visible labels and accept names according to actual needs instead of arbitrarily requiring a first/last split. Test autofill, manual correction and server validation: a prefilled field becomes neither verified contact information nor permission to send to another person.

• Values reach the correct fields and errors allow correction without losing other answers.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

• MDN HTML Autocomplete

  HTML attribute indicating expected information types and hints for automatic form filling.

Verify the received request

Proposed case: a form shows success while its recipient received nothing. The screen confirmation does not complete the processing journey.

Test fictional data in an authorised environment. Connect action, response, receipt and follow-up owner; distinguish send failure, message filing and lack of handling.

• Use an identifiable fictional request
• Confirm expected receipt
• Identify the follow-up owner

• Preserve input after an error

  Write form errors that help people recover

Do not confuse submission and receipt

An on-screen confirmation establishes only the state the server can confirm. Test delivery to the business mailbox, the ability to reply and duplicates after a retry. On failure, provide a usable next step and retain non-sensitive fields where the context permits.

Write four messages to match the submission outcome

Fictional example: a maintenance enquiry passes through the states below. Explain what is established and what the person can do next. An enquiry reference can support tracking; it is not evidence that the team has read it.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

• W3C WAI · User Notification

  These are editorial examples. The WAI tutorial explains form feedback and associating errors with controls; adapt the wording to the handling actually provided.