La Ventana, Baja California Sur, México. [email protected]
←Journal
·7 min read

How Many Fields Should a Contact Form Ask For?

Contact forms grow field by field until they feel longer than the conversation they start. Here is what checkout research shows about form length, how a question protocol keeps service inquiry forms short, and which fields to require, hide, or drop.

Windware Studio· Design & Development Team

A service business often treats the contact form as a scoop: name, email, phone, company, budget, timeline, how they found you, and a message box “just in case.” Each field feels reasonable alone. Together they turn a simple next step into homework.

Form length is a design decision, not a CRM wish list. This article uses Baymard Institute research on how the number of form fields affects checkout usability, then applies the UK government’s question-protocol approach so an inquiry form asks only for information the business can justify using.


Why form length feels heavier than page count

People judge effort by what they have to complete, not by how the designer grouped the screens. Baymard’s research lead Edward Scott made that point for ecommerce checkouts in Checkout Optimization: Minimize Form Fields, published 26 June 2024. The article reports that the average checkout flow in their 2024 ecommerce UX benchmark was 5.1 steps long and contained 11.3 form fields—and that 17% of users had abandoned due to checkout complexity (finding #GC050).

The more useful finding for designers is the comparison between steps and fields. Baymard found that as the number of form fields increases, overall checkout UX performance decreases, and that form-field count generally affects usability more than step count. In their research, most sites need only eight form fields in total for a checkout flow, yet the 2024 average was 11.3 fields (down slightly from 11.8 in 2021 and 12.7 in 2019).

A contact form is not a checkout. The parallel still holds: visitors notice how many boxes they must fill, and optional fields that sit in plain view still cost attention. On a phone, every extra field also lengthens the scroll before the submit button.

What goes wrong when every stakeholder adds a field

  1. The form collects data nobody will use. Budget ranges and “how did you hear about us?” sit in a spreadsheet and never change how the reply is written.
  2. Required fields block people who are ready to talk. A visitor who will not share a phone number on first contact leaves without sending anything.
  3. Visible optional fields look required. Empty coupon-style extras and secondary address lines teach people to treat the whole form as unfinished work.

What Baymard’s field-reduction patterns teach inquiry forms

Baymard’s recommendations are written for checkout, but several patterns map directly onto service contact forms because they reduce what users must consider, not only what they must type.

One name field instead of two

Across Baymard’s checkout studies, users generally treated their name as a single entity. When sites split first and last name, 42% of participants typed their full name into the “First Name” field at least once. On sites that used a single “Full Name” field, only 4% of users briefly hesitated before typing, and none showed the typing or interaction issues seen with multiple name fields. Despite that, 89% of sites in the benchmark still used more than one name field.

For a contact form, a single name field is usually enough to personalize a reply. Split names only when a downstream system truly requires them—and even then, prefer collecting the split later rather than on first contact.

Hide fields most people do not need

Baymard found that 30% of participants stopped when they reached “Address Line 2,” while people who needed that line actively looked for it. Hiding it behind a link removed a field most users did not need. Their benchmark still showed 75% of sites leaving Address Line 2 visible by default.

The same pattern applies to inquiry forms. Fields such as company name, preferred call time, or attachment upload can stay available without appearing as empty boxes on every visit. A link labeled “Add company details” or “Prefer a call back?” keeps the default path short.

Delay account-like demands

Baymard also found that pushing account creation early forces users to confront password and profile fields before they have finished the main task; 84% of sites in their research failed to delay account creation until after order confirmation. An inquiry form that demands a password, a full postal address, or an account before the visitor can send a question creates the same kind of early friction. Collect identity details that are only needed to deliver the service after the conversation starts.

“Every field on a contact form is a question you are asking a stranger before they have agreed to talk. Ask only the questions you can defend.”
— Windware Studio Practice Note


Use a question protocol before you design the form

The UK government’s Service Manual, in Structuring forms (published 7 December 2016; updated 7 August 2018), asks teams to make a list of every piece of information they need from users before they design the interface. That list is a question protocol. A question is added only when the team knows:

  • that they need the information to deliver the service
  • why they need it
  • what they will do with it
  • which users need to give it
  • how they will check it is accurate
  • how they will keep it up to date and secure

The protocol is deliberately separate from the form layout. It gives the organization a way to push back on fields that feel traditional rather than necessary. The GOV.UK Design System’s question-pages pattern repeats the same rule in design language: only ask for information you really need, and ask for a piece of information only once in a journey.

For a studio or service firm, a practical protocol for first contact might look like this:

FieldNeeded to reply?WhyWhat we do with itKeep?
NameYesAddress the personUse in the replyRequired
EmailYesSend the replyRoute inquiryRequired
Message / needYesKnow what they wantQualify and respondRequired
PhoneSometimesCall-back preferenceCall only if offeredOptional / link
CompanySometimesContext for B2B workCRM recordOptional / link
BudgetRarely at first contactSales qualificationOften unusedDrop or ask later
How did you hear about us?No for replyMarketing reportAggregate laterDrop or ask after

Start short; merge only when research says so

GOV.UK guidance recommends starting with one thing per page for complex government services, then merging pages when research shows users can handle more. A single-page contact form for a small business is usually fine; the principle that matters is the same: do not start from the longest possible form and trim. Start from the protocol’s minimum, then add a field only when a real failure (missed context, unusable replies) shows the gap.


A field audit checklist for your current contact form

  • List every visible field and mark required vs optional.
  • Run each required field through the question protocol. If you cannot answer why and what you will do with it, it is not required.
  • Count fields users must consider, including optional ones shown by default.
  • Collapse low-frequency fields behind a link or progressive disclosure.
  • Use one name field unless a system constraint forces a split.
  • Move sales-qualification questions (budget, timeline, company size) to the reply conversation or a follow-up form after interest is confirmed.
  • Check the form on a phone. If the submit button is far below the fold after the required fields, the form is still too long for first contact.

Tradeoff to accept

A shorter form gathers less structured data up front. That can annoy a sales process that wants every lead pre-scored. The tradeoff is intentional: you exchange spreadsheet completeness for a higher chance that the person who is ready to inquire actually sends the message. Structured details can be collected in the reply thread, on a booking page, or in a second step after the visitor has opted in.


Practical takeaways for your next website

  1. Design from a question protocol, not from the CRM’s default lead fields.
  2. Treat visible optional fields as part of the effort cost. If most visitors do not need them, hide them.
  3. Prefer one name field and a clear message box over a long grid of half-used inputs.
  4. Require email (or another channel you will actually use) and the description of the need. Everything else must earn its place.
  5. Re-audit after a few weeks of inquiries. If a dropped field never would have changed a reply, keep it dropped.

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.