Searching for the best form design mostly returns galleries. Screenshots of forms with generous whitespace, a soft gradient, an illustration on the left, and a submit button in a colour that took somebody a week to choose. Some of them are genuinely good. None of the screenshots can tell you whether anybody finished the form, and none of them can tell you whether the answers were any use to the team that received them.
That second question is the one that gets left out of almost every form design article, and it is the one that decides whether a form was worth building. A form that half the visitors complete, producing answers so thin that every submission needs a follow up email, is not a better form than a slightly longer one that produces a usable answer the first time.
Best is measured against a job, not a look
Before any design decision, there is a sentence to write down: what has to be true after this form is submitted for nobody to need to chase anything.
For a newsletter signup that sentence is short. An address that works. For a quotation request it is longer, and it usually includes the thing the person wants, roughly when, and some sense of scale. For a job application it includes whatever the first screening decision actually turns on.
Writing the sentence does two things at once. It names the fields that have to exist regardless of how much they cost in completions, and it exposes the fields that are in the form because somebody once asked for them and nobody has since removed them. Almost every form built more than a year ago has at least one of those.
The trade off is real in both directions, which is why "keep it short" on its own is bad advice. Cutting a field that the team genuinely needs does not save work, it moves it. The saving shows up in the completion rate and the cost shows up as an email thread. A form that is short because it asks almost nothing generates leads nobody can act on, which is the failure mode of the prettiest forms in every gallery.
Best, then, is the shortest form that still answers the question in that sentence. Everything below is about finding it.
Start by subtracting: three tests for a field
Take the field list and run each one through three questions, in order. The order matters because the first test disqualifies the most fields for the least argument.
Will the answer change what happens next? Not might, in some future version of the process. Will it, this month, change who handles the submission, what reply gets sent, or whether it is accepted. If not, the field is collecting data for a report nobody reads.
Can it be derived instead of asked? A great deal of what forms ask for is already available. The page the form sits on tells you which product the enquiry is about. The time of submission is recorded. The referring page, the language, and often the country are known. Asking a person to type something the system already holds is the clearest possible waste of their attention.
Can it be asked later, in the reply? This is the test that rescues the fields that survive the first two but are still expensive. A budget range, a preferred date, a file, a detailed description. Each of these is answerable in a reply to a person who has already made contact, and asking it in the reply costs the team one sentence while asking it in the form costs some fraction of every visitor.
| Field | Test it fails | What to do instead |
|---|---|---|
| How did you hear about us | Does not change what happens next | Read the referrer, or drop it |
| Which product | Can be derived | Set it from the page the form is on |
| Company size | Rarely changes the next action | Ask in the reply, if at all |
| Budget | Changes what happens next, but costs completions | Ask in the reply, on the first response |
| Phone number | Changes nothing if the reply goes by email | Optional, or ask when a call is agreed |
| Detailed description | Changes what happens next | Keep, but one paragraph box, not required |
| Email address | Changes everything | Keep, required, verified format |
The pattern is that fields survive when the next action genuinely depends on them, and that most of what a person gets asked to type is either already known or could wait. A form of five fields that captures the enquiry and a reachable address will outperform a form of fifteen that tries to complete the qualification in one pass, provided the team on the other side is actually able to reply.
What to do with the fields you cut
Cutting a field is not the same as deciding never to know the answer, and this is where the practice usually falls apart. The fields come back within a month, one at a time, because the team keeps needing the information and nobody wrote down where it was supposed to come from instead.
Three destinations cover nearly all of them.
Into the reply. The first response to an enquiry is going out anyway, and a question in it gets answered by someone who is now in a conversation rather than facing a wall of inputs. This is the right home for anything that requires thought.
Into an internal field. Some of what gets asked on forms is not for the respondent at all. Status, source, priority, whether they were a good fit, what was agreed. Putting these on the form is a category error, because the person filling it in does not know the answers. They belong to the team, recorded against the response after it arrives, which is also how they end up in the export in the same row as the answers.
Into nothing. Some fields genuinely have no destination, and that is the finding rather than a problem. A field whose answers have never been read by anyone can be removed without a replacement.
The second destination is the one that changes how a form is designed, because once a team has somewhere to record its own notes against a submission, the pressure to ask the respondent everything up front drops away. The use cases page shows the shape of that split for applications and enquiries, where the form is short and the record it creates is not.
The words do most of the work
Layout gets the attention and copy does the work. Three places repay the effort.
The line above the form. One sentence saying what this is for and what happens after. It sets the exchange, and it is the difference between a form that reads as a request and one that reads as a data grab.
Field labels. Short, concrete, in the words the respondent would use rather than the words the internal system uses. A label that matches a database column name is a reliable sign that nobody outside the team has read the form. Where a field needs explanation, put it as help text under the label, visible at all times, rather than in a tooltip or a placeholder.
The button. The label on the button should name what is about to happen. Send enquiry, Book the call, Submit application. The word Submit on its own is the default because it is what the control is called in the specification, not because it reads well.
One more piece of copy is often missing entirely, which is the explanation for a field that looks intrusive. A single clause is usually enough. A phone number field with "so a callback can be arranged" beside it gets filled in far more readily than the same field alone, because the person is no longer guessing at the motive.
Design that survives a real browser
A form that looks correct in a design file meets four conditions in the wild that the design file does not model.
Autofill. Browsers will repaint filled fields in their own colours, which can override a carefully chosen background and, in some combinations, drop the text contrast. Any form design has to be checked with autofill actually triggered rather than with fields typed by hand.
The respondent's own display settings. A dark mode preference, a larger default font size, or a page zoom of 150 percent all change the layout. Zoom is the one that breaks things, because a layout built on fixed heights starts clipping. One defence is to render public forms in a fixed light theme so that nothing shifts with the viewer's settings, which trades a preference for predictability.
The keyboard, for people not using a mouse. Tab order follows the order of the markup, so a visually reordered layout can produce a tab sequence that jumps around. Every control needs a visible focus state, and removing the default outline without replacing it is the most common accessibility regression in form design.
Required markers that do not rely on colour. Where a form mixes required and optional fields, the marking has to work without colour vision, which means descriptive text or an icon rather than a red label. In the markup, the required attribute on an input, select or textarea both blocks submission and tells assistive technology that the field is needed; the aria-required attribute carries the same meaning for controls built from non semantic elements, though it changes nothing about behaviour on its own.
How to tell whether a change worked
Most form redesigns are never measured, which is why the same debates repeat. Three measurements are enough, and none of them needs a specialist tool.
Starts against completions. A count of people who interacted with the first field, against a count of submissions. The ratio is the number that any design change has to move. Page views are not a denominator, because they include people who never intended to fill anything in.
Where the last interaction was. For abandoned sessions, the field they were on when they stopped. This single list is worth more than every general best practice, because it names the specific field costing the most and it is different on every form.
The quality of what came in. Count how many submissions needed a follow up question before anything could happen. This is the measurement that catches an over shortened form, and it is the one that never appears in a form design gallery.
Change one thing at a time, and give it enough submissions to mean something. On a form receiving a handful of submissions a week, that means weeks rather than days, and a change judged after two days is being judged on noise.
What to change first
Write the sentence describing what has to be true after a submission, then delete every field that does not serve it and move the expensive ones into the first reply. Start counting starts against completions before the next change, so the one after that can be judged rather than argued about, and if the team needs somewhere to keep its own notes against each response instead of asking the respondent for them, that is what Halict uses internal fields for.
Q1. Is a shorter form always better?
No. Shorter forms are completed more often and can produce answers too thin to act on, which moves the work into a follow up email instead of removing it. The target is the shortest form that still answers what the team needs to decide the next step, which is usually fewer fields than exist and more than none.
Q2. How many fields should a contact form have?
Enough to reply usefully, which for most enquiries means a reachable address, a name, and a free text box. Everything else should be tested against whether it changes the next action. A phone number, a company name and a budget range can all be asked in the first reply at far lower cost.
Q3. Should optional fields be included at all?
Only where a meaningful number of people will answer them and the answer is useful. An optional field still takes up space and attention, and a long form of optional fields reads as long regardless of the marking. If almost nobody fills it in, that is the answer about whether to keep it.
Q4. What is the best place for a field label?
Above the field and left aligned, for nearly every form. The eye travels a short distance to the input, the pairing holds on a narrow screen, and the label stays visible once typing begins. Labels inside the field as placeholder text disappear at the moment they are most needed.
Q5. How long should a change be left before judging it?
Long enough for the number of submissions to be more than noise, which on a low volume form means weeks. Comparing two days against two days will show a difference on any form, in either direction, and acting on it is how teams end up reversing the same decision twice.
Q6. Does the visual design of a form matter at all?
It matters for trust and it matters for legibility, both of which affect whether people start. What it does not do is rescue a form that asks for too much or one that leaves the submission somewhere nobody owns. Spend the first effort on the field list and the reply, then on how it looks.