Keep your form short and clearly labelled, put a phone number or email beside it, and tell people exactly when they will hear back. A few elements do most of the work: minimal fields, a descriptive submit button, and a visible confirmation message backed by an email receipt. Treat accessibility checks and real-user testing as non-optional before you publish.
TL;DR:
- Match the layout to visitor intent: contact hubs route sales, support, and press; maps serve walk in businesses, while booking pages collect call preparation details.
- Use name, email, and message as the core fields; add phone, company, or enquiry category only when the team needs them.
- WCAG 2.2 AA requires programmatically associated labels, written error instructions, and sufficient colour contrast; UK sites should also publish an accessibility statement.
- Keep forms on one screen unless they are complex; guidance suggests splitting them above around ten questions, with progress, back navigation, and saved answers.
- Track page views, submissions, drop off by field, and success rates, then test one change at a time and scrutinize mobile completion.
Table of Contents
- Which contact page layouts are worth copying?
- What design rules increase form completion and trust?
- Which fields should a contact form include?
- What does an accessible contact form need?
- When should a contact form be split into steps on mobile?
- How should a contact form handle errors?
- How do you test a contact form and track its performance?
- Where can you find accessible contact page templates?
- Our approach to contact pages in client work
- How can we help you build a high-converting contact page?
- FAQ
- Sources
Which contact page layouts are worth copying?
Contact pages tend to follow a handful of patterns. Pick the one that matches what your visitors actually want to do, then trim everything else away.
- Minimal lead capture: a one-line intro, then name, email, message and a submit button. This suits general enquiries and service businesses that want a low-friction first contact.
- Contact hub: categorised contacts for sales, support and press, plus phone numbers, opening hours and a form that creates a ticket. It works best when different people need different answers.
- Map plus local details: an embedded map, the full address, parking notes and a short form. Walk-in and local businesses benefit most, because visitors often just need directions.
- Booking layout: a scheduling link or embedded calendar alongside a short intake form that captures only what you need to prepare for the call.
- Chatbot first: a prominent chat entry point with a short form as the fallback when nobody is online. Keep the form visible, because chat will not suit everyone.
If you want to see our work, browse our portfolio. For wider inspiration on how other agencies present themselves, this roundup of B2B web design agencies is a useful browse.
What design rules increase form completion and trust?
Every extra question is a reason to leave, so the rules below are mostly about removing friction and adding reassurance.
- Limit the field count. Ask only for what you need. A single name input beats separate first and last name fields unless you genuinely need a legal name split.
- Write a benefit-driven button. “Send enquiry” with a line beneath such as “We’ll reply within 48 hours” beats a bare “Submit”. Setting expectations about response times builds trust and turns a form into a conversation rather than a data grab.
- Show trust signals. Business hours, a stated response time, a short testimonial or a row of client logos all reassure a hesitant visitor. Our guides on website essentials that build trust and social proof examples cover what to borrow.
- Keep a clear visual hierarchy. Headline, form, then alternatives. Nothing should compete with the button.
- Match field size to the input. Visitors read width as a cue, so a short field for a phone number and a tall one for a message tells them what to type. Mismatched widths can reduce completion.
Which fields should a contact form include?
Here is a checklist you can paste into a brief or hand straight to a developer.
- Name: one text input, labelled “Your name”, with
autocomplete="name". - Email:
type="email", labelled “Email address”, withautocomplete="email". - Message: a textarea labelled “How can we help?”, sized for a few lines of text.
- Phone (optional):
type="tel"withautocomplete="tel", marked as optional in the label itself. - Company and enquiry category (optional): only if your team genuinely routes enquiries differently.
- Labels over placeholders: use meaningful HTML elements, a label on every field, and correct
typeandautocompleteattributes so browsers can autofill accurately. - Placeholders as hints only: an example format such as [email protected] is fine, but never let a placeholder replace the label.
What does an accessible contact form need?
Accessibility is a legal and practical baseline for UK sites, and a contact form is where it matters most, because it is where a visitor tries to become a customer. The WCAG 2.2 AA standard asks for explicit, programmatically associated labels on every control, clear error identification with text explaining how to fix each problem, and sufficient colour contrast. Our colour contrast workflow shows how to check this in practice.
Beyond the form itself, publish an accessibility statement and link it from your footer. It should say how compliant the site is, describe any inaccessible parts, offer alternatives and tell people how to report problems.
The W3C’s forms tutorial covers labels, instructions and grouping controls with fieldsets, while Success Criterion 3.3.2 asks for concise instructions wherever input is needed. If you are unsure where you stand, an accessibility audit is the quickest way to find out.
When should a contact form be split into steps on mobile?
Most contact forms should stay on one screen. Multi-step layouts earn their place only when the form is complex. One public-sector design guide suggests that a form with more than around ten questions may be worth splitting across pages, and that every question must be vital.
On a phone, speed comes from small details. Choose the right input type so the correct keyboard appears, and set field widths to match the expected input, as the web.dev design basics advise. If you do use steps, show a clear progress indicator, let people go back, and keep what they have already typed. Nothing frustrates a visitor more than retyping an email address.
How should a contact form handle errors?
Never rely on colour alone. WCAG 3.3.1 requires errors to be shown in text, naming the field in error and explaining how to fix it. That text can sit inline, in a summary, or both.
A good inline message reads: “Please enter a valid email address, for example [email protected].” Where several things go wrong at once, add a single summary alert at the top that links to each problem. When the form succeeds, show a clear success message on screen and send a confirmation email as a receipt, repeating the response time you promised.
How do you test a contact form and track its performance?
Start by testing with real people on several devices, and check cross-browser behaviour with a tool such as BrowserStack. Then instrument the page. Track page views, form submissions, field-level drop-off and success rates, so you can see exactly where people give up.
Once you have a baseline, run small experiments on one variable at a time: field count, button wording, or form placement. Use A/B testing to confirm that a change really helped, and pay particular attention to mobile completion, where problems tend to hide.
Where can you find accessible contact page templates?
Look for HTML templates and CMS form blocks that already include labelled controls and example error states. Adapt a template when your brand is flexible and your timeline is tight. Build custom when your design is distinctive or your accessibility needs go beyond the template’s defaults. GOV.UK suggests following the Design System patterns as a sound starting point.
Whichever you choose, run this adaptation checklist:
- Add a visible label to every field.
- Set
autocompleteand input types. - Write specific error text for each field.
- Add a confirmation message and receipt email.
Our approach to contact pages in client work
We run a collaborative process built around quick iteration, and the contact page is rarely where we want to add complexity. Our usual advice: keep the form short, make the follow-up promise explicit, then measure what happens and adjust. The numbers tell us more than opinion ever does. If you want to see these patterns applied, browse our work.
— Kukoo
How can we help you build a high-converting contact page?
Everything in this guide is something we do day to day. Our Web Design & Development and UX / UI Design services cover the layout, the form and the testing, and our Visual Identity work makes sure the page looks like you. If your branding needs a refresh first, the Logo Design Brief is a simple place to start. Tell us what you are working on and we will take it from there.
FAQ
What should a contact page include?
At minimum, a short form with name, email and message, plus at least one alternative way to reach you, such as a phone number or email address. Add your opening hours and an honest response time so visitors know what to expect.
How many fields should a contact form have?
As few as you can get away with. Every field is a chance for someone to abandon the form, so ask only for what you genuinely need to reply. Public-sector guidance suggests that around ten questions is the point to consider splitting a form into steps.
How do you make a contact form accessible?
Give every field a programmatically associated label, explain errors in text and say how to fix them, and keep colour contrast strong. These are core requirements of WCAG 2.2 AA. Publishing an accessibility statement is the final step.
How do you know if a contact page is working?
Track submissions against page views, then look at where people drop off field by field. web.dev recommends testing with real users and validating changes with A/B tests.