A contact page should help a visitor choose the right route, send the information needed and understand what happened next. Start by mapping enquiry types to real owners, then design clear contact choices and a short accessible form. Test the complete journey through receipt and routing, including errors and unavailable destinations.
A telephone link, email address and form are different ways to begin a conversation. Give each a recognisable purpose. A visitor asking about an existing order should not have to infer whether a general sales form reaches support. Equally, a simple first enquiry should not require an account or a detailed project specification.
The useful design deliverable is a route map with evidence that every destination works. Visual polish matters, but a beautiful contact page that sends a message into an unmonitored mailbox has failed its central task. The original worksheet below joins the public choices to the people and checks behind them.
Which contact choices does the visitor actually need?
Begin with the questions visitors bring: a new project, an existing service, an invoice query or a general enquiry. Group routes only when the same team genuinely owns them. Use wording a visitor understands rather than internal department names. Put the general route within easy reach for someone whose question does not fit a category.
For each choice, write the destination and the information needed to act. A new-project enquiry might need a reply address and a short description. An existing-service enquiry might benefit from a reference, but make clear how someone without that reference can proceed. Collecting extra detail should serve the conversation rather than merely filling a database.
Make telephone and email choices usable as ordinary text as well as links. Describe any published contact hours accurately and keep them under an identified owner’s control. Promise a response time only when the business has authorised and can support that promise. A contact page can be helpful without inventing an immediate-response commitment.
How should the form explain its fields?
W3C recommends labels that describe the purpose of the form control. A field called “Details” leaves more interpretation to the visitor than “What would you like help with?” Review labels with the person who handles the messages: they should prompt information that makes the next action possible. W3C’s labels tutorial provides the implementation foundation.
An explicit label’s for attribute must match the control’s id exactly. Give repeated or dynamically inserted fields distinct identifiers and inspect the rendered page. A label that looks adjacent to an input is not enough evidence that their programmatic association is correct. Include the chosen label, field identifier and required status in the design handover.
Browsers make the associated label a larger clickable area. That makes the label itself part of the interaction. Test it by clicking or tapping the text, especially beside small checkboxes. W3C generally favours explicit labels for assistive-technology support. Prefer a visible, directly associated label for ordinary contact fields instead of introducing a more complicated technique without a reason.
W3C describes the title attribute as a less reliable way to identify controls. Do not make a hover tooltip the only explanation of what to enter. Write essential instructions beside the field and keep them available while a person types. Where a field has a particular format, show a useful example without replacing its persistent label. These decisions make the form easier to inspect and maintain too.
What should happen when submission fails or succeeds?
W3C recommends notifying users whether form submission succeeded or produced errors. The W3C notifications tutorial treats feedback as part of completing the form. Specify separate messages for a field error, a delivery failure and a successful receipt. Those states have different meanings and should lead to different next actions.
An error list should identify the corresponding control by its label. W3C recommends linking listed errors to the corresponding controls. Together, these recommendations make an error summary actionable. “Please check the form” is much weaker than identifying the affected field and explaining how to fix it. Keep valid entries when redisplaying the form so a visitor can concentrate on the correction.
The aria-describedby attribute can associate a form field with its error message. Ask the implementer to show that relationship in the rendered markup and then test the spoken result with assistive technology. After an invalid submission, W3C describes focusing the first erroneous input as convenient. Include the focus behaviour in keyboard testing, alongside the path through the summary links and back to the submit button.
A success message should describe what the system has actually established. “Your enquiry has been received” is appropriate only when receipt has been confirmed. Do not equate a button animation with message delivery. Keep internal delivery diagnostics private while giving visitors a useful alternative when the normal route fails.
Original contact-route worksheet
The following hypothetical example concerns a small service business with a general enquiry inbox and a separate existing-work queue. It is a design exercise. Replace the proposed owners with real responsibilities and record observed results before accepting the page.
| Visitor task | Public choice and minimum information | Internal owner to name | Evidence to retain |
|---|---|---|---|
| Ask about new work | New enquiry; reply address and short request | Person monitoring the enquiry inbox | Test message arrives with the chosen category |
| Discuss existing work | Existing enquiry; optional project reference | Delivery contact or agreed queue owner | Reference and message remain together |
| Ask an unmatched question | General contact option | Named triage owner | Message receives an explicit next owner |
| Correct invalid input | Error summary and field guidance | Form maintainer | Keyboard path reaches the affected field |
| Retry after delivery failure | Clear failure notice and another contact route | Technical owner plus inbox owner | Failure is visible and no false receipt appears |
Create a test enquiry labelled clearly as a test. Record the route chosen, submitted values, displayed result, destination and person who checks the destination. Use a harmless fictional reference. Ask the receiving owner to confirm the category and reply address, rather than accepting a screenshot of the public page as proof of routing.
Next, submit the form with a missing required value. Write down the expected message, the actual message and the focused element. Correct the error using only the keyboard and submit again. Check that previously valid text remains available and that any success notice can be understood without relying on colour alone.
Then test a destination failure in an agreed test environment. Decide what a visitor should do when delivery cannot be confirmed, and what evidence the internal team receives. Give the failure path a named owner. A fallback email address is only useful when it is current and monitored; check it as deliberately as the form.
Finally, change the enquiry category midway through a draft message. Confirm that the submitted category and actual destination agree. This catches a subtle design problem: the screen may show a new choice while hidden routing data still contains the original value. Record that case separately from basic required-field validation.
What belongs in the contact-page handover?
Keep a compact register of public contact details, destinations, form fields and owners. Record who can approve a changed address and who checks the page after the change. Include the success and failure wording so later edits do not accidentally turn a technical acknowledgement into an unsupported service promise.
Review the page at narrow widths with long input and long error messages. Check that help text stays with its field and that contact choices remain understandable when stacked. Ask a colleague unfamiliar with the internal routing to choose a route for each example in the worksheet and explain their choice.
A sound handover lets the business answer three practical questions: where will this enquiry go, how will the visitor know what happened, and who fixes the route when it stops working? Use web design and web development for wider project context. To discuss a contact-page brief, get started with your route worksheet and the contact details you want verified.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.