Ask fewer, more useful form questions

Give every question a job

GOV.UK's form-structure guidance describes a question protocol: record why information is needed and how the service will use it before adding the question. For a small website team, a simple working list is enough. Put the proposed question beside the decision it supports and the person who uses the answer.

Review that list with whoever handles submissions. If nobody can explain what changes because of an answer, leave the question out of the first version. A preference for having a fuller record is different from a practical need to reply, route the request or understand the problem.

Separate the first conversation from later work

An enquiry does not need to collect everything that a completed project will eventually require. A team can often respond to a short description and contact address, then ask for detailed specifications once the request is understood. Write the form around that first useful exchange.

For example, a volunteer enquiry can ask which activity interests the person and when they are broadly available. A later conversation can establish the details appropriate to the role. Do not turn a simple expression of interest into an extensive application unless that is the actual task the page promises.

Make the remaining questions answerable

Reducing fields is not the same as merging everything into one vague request for details. GOV.UK's question-writing guidance encourages clear questions and valid uncertainty options. If a visitor may not know their timeframe, an honest Not sure yet option can be more useful than a guessed date.

Try the wording with someone outside the team. Ask them to explain what they think the question means before answering it. If they interpret it differently, revise the label. Keep optional details visibly optional, and avoid making a telephone number mandatory when your stated follow-up happens by email.

Decide what happens after collection

A short form still needs an owner. Decide who reads new entries, what happens to unrelated information and when completed requests should be removed from the working queue. Match the public explanation to the team's real process, including the destinations used for email notifications.

Review the form after the team has handled real requests. Look for questions routinely ignored, requests that need the same follow-up and instructions that invite too much detail. Change one problem at a time. Keep a note of why a field was added or removed so that future edits do not quietly recreate the old form.

Using Accessible Forms

Use fewer questions first. Settings for storage and advanced routing support that decision but do not replace it.

In Free: Free provides required and optional field settings, per-form retention controls and a minimal-metadata option that omits the stored IP hash and browser information from entries.

With Pro: Pro can show conditional questions for relevant answers. Answers excluded by active server-side field conditions are excluded from the stored submission.