Enquiry forms that people actually finish

A form fails for a specific, checkable reason far more often than it fails from being “too long” in the abstract. Labels that disappear when a field is focused, error messages that do not say which field is wrong, and forms that discard everything typed after one validation failure account for more abandoned enquiries than field count alone — and all three are fixable without a redesign.

What actually breaks a form

Labels that vanish. A placeholder used as the only label disappears the moment someone starts typing, so a person who is interrupted — which describes most people filling in a form on a phone — returns to a blank-looking field with no reminder of what it wanted. WCAG 2.2’s Labels or Instructions criterion requires labels or instructions to be provided for user input, and a persistent visible label (not a placeholder alone) is the reliable way to meet it.

Errors that do not say what is wrong. “Please check the highlighted fields” without naming the field, or a red border with no text, forces a re-read of the whole form. An error message that names the specific field and the specific problem — “Phone number needs at least 8 digits” — is fixable in most form libraries with a template change, not a rebuild.

Data loss on error. A form that clears every field because one was invalid punishes the person for a single mistake. This is one of the most common and most avoidable failures, and it is almost always a configuration error rather than a design choice.

Asking for information the business does not act on. Every field on a form should have a use the business can name. “How did you hear about us” is useful for the business and can sit in analytics via the attribution already captured by the browser rather than by asking the visitor to remember and self-report it — see UTM tags and campaign tracking for how that attribution is captured without an extra field.

What Australian law requires structurally

A form that collects personal information sits under the Australian Privacy Principles, and a form that is used to build a marketing list sits additionally under the Spam Act’s consent requirements. Practically, this means:

• A form should make clear at the point of collection what the information will be used for, particularly where a tick-box adds the person to an ongoing marketing list rather than simply logging a single enquiry.
• Consent to receive marketing communications should be a genuinely separate choice from submitting the enquiry itself, not bundled into a single unavoidable checkbox.
• Whatever is promised at the point of collection — “we’ll only use this to respond to your enquiry” — has to be true, because it is a representation the business is making about its own conduct.

None of this is legal advice; if a form is collecting sensitive categories of information or feeding an ongoing marketing database, get advice specific to that use.

The genuine trade-off in field count

Removing fields does not remove the underlying questions a business needs answered to give a useful reply — it moves them to a follow-up phone call or a second email, which is a worse experience for a visitor who wanted a single interaction. A plumber asking “urgent or routine?” up front is not adding friction; it is preventing a missed emergency from sitting in a queue meant for routine quotes. The right test is not “how few fields” but “does every field change what happens next” — see how many fields a form should have for the specific version of this question.

Letting the browser help, rather than fighting it

Modern browsers can autofill a name, phone number, email address and postal address automatically, but only when a form’s fields use the correct HTML input types and autocomplete attributes to tell the browser what each field is for. A form built with generic text inputs and no autocomplete hints forces every visitor to type everything by hand even on a device that could have filled most of it in a tap, which is friction with a straightforward technical fix rather than a design problem.

Validation needs to happen twice, for different reasons

Client-side validation — checking a field as the visitor types or on submission, before anything is sent — gives immediate feedback and is what makes the error-handling behaviour described above possible. Server-side validation, checking the same rules again once the data actually arrives at the server, is a separate and non-optional layer, because client-side checks can be bypassed entirely by a visitor with the technical means to do so, and any business relying on the submitted data (routing an urgent enquiry correctly, for instance) needs the same rules enforced where it cannot be skipped.

A short, checkable list

Check	Why it matters
Every field has a persistent visible label	Placeholder-only labels disappear on focus
Error messages name the specific field and problem	Generic errors force re-reading the whole form
A validation error never clears already-entered fields	Data loss after one mistake is the single most punishing failure
Required fields are marked, and only genuinely required fields are required	Marking everything required when it is not increases perceived effort
The submit button states what happens next (“Send enquiry”, not “Submit”)	Ambiguity about the outcome of clicking adds hesitation
Marketing consent is a separate, genuine choice from the enquiry itself	Spam Act and Australian Privacy Principle obligations

What this page calls an “enquiry form,” a contact form, and an application form

Many businesses use “contact form” and “enquiry form” interchangeably for the same page, and the structural facts on this page apply regardless of which label a business’s own website uses. A sales enquiry form is a different job from an application form or an event registration collecting attendee details for a specific date — those forms trade the same design principles against different constraints, because a form nobody has to fill out twice a year tolerates more friction than one a business genuinely needs completed today.

Most form-builder templates ship with placeholder-only labels by default, which is the single most common way the first failure on this page’s checklist gets reintroduced without anyone choosing it deliberately — a generic template dropped in unmodified carries its defaults, not this page’s recommendations, unless someone specifically checks it against them.

What to do next

Check an existing form against the table above before commissioning a redesign — most of it is a template or copy change, not new development. For the field-count question specifically, read how many fields a form should have. For the underlying build work a form with correct labelling, validation and error handling actually requires, web development services covers where that sits in a typical project.