Build a lead form that earns every question it asks

Start with the next useful response

Write down what a colleague needs to do after receiving an inquiry. If the next step is a short call to understand the project, the form may need a name, reply method, broad service interest and a concise description. It probably does not need a budget broken into narrow bands, a full address or answers to questions better handled in conversation. A field earns its place when it changes routing, eligibility, preparation or the quality of that first response.

Separate information needed now from information needed after the business accepts the work. Asking for everything at once raises effort and creates more personal data to secure. The UK ICO’s data-minimisation guidance says personal data should be adequate, relevant and limited to what is necessary for the purpose. Record the purpose before adding the field, and remove it when the team cannot explain how the answer is used.

Complete this field-purpose worksheet

Create one row per proposed field. Review it with the person who answers inquiries and the person responsible for privacy or operations. If a field is “nice to know,” leave it out of the first version.

• Question and label: What plain-language question will the visitor see, and does the label remain visible after an answer is entered?
• Decision supported: Does the answer affect eligibility, routing, preparation or the next reply? Name the exact decision.
• Required or optional: What prevents a useful response if the visitor leaves it blank?
• Format and validation: Which values are accepted, which examples help and how will an error explain the correction?
• Storage and access: Where is the answer durably saved, who can see it and how long is it needed?
• Sensitive content: Could the question invite health, financial or confidential details that are unnecessary at this stage?
• Owner: Who monitors submissions, corrects failed handoffs and removes a field when its purpose changes?

Make labels, instructions and errors work together

W3C’s forms guidance calls for labels that identify controls and are properly associated with them. Keep a visible label even when placeholder text offers an example. Group related options with a clear legend. Put format guidance before submission rather than revealing every rule only after an error. Mark required fields in text or another programmatically understandable way, not with color or an unexplained symbol alone.

Validate on the server as well as in the browser, but preserve the visitor’s safe entries when correction is needed. Move focus or provide a clear error summary so keyboard and screen-reader users can find the problem. Write specific messages: “Enter an email address in the format name@example.com” is more useful than “Invalid value.” Do not treat unusual punctuation in a person’s name or business description as hostile merely because it differs from a narrow sample.

Hypothetical example: a repair-service inquiry

Consider a hypothetical workshop that repairs commercial coffee equipment. Its form asks for contact name, work email or telephone, equipment category, business postcode and a short description. The postcode changes whether the team offers on-site assessment, while the equipment category routes the inquiry to the right technician. A photograph is optional and its supported types and size are explained before selection.

The form does not request payment details, serial numbers or a full service history. Those are collected securely if the workshop accepts the request. After submission, the visitor sees a reference and an honest statement of what happens next. The saved record appears in an owner queue even if an email notification fails. A clearly labelled sample with an unsupported image tests the correction path without using a real customer’s details. This is a hypothetical planning example, not a Kinetivy client result.

Design consent and every submission state

Explain why information is requested near the form and link to the relevant privacy information. If optional marketing is offered, keep that choice separate from sending the inquiry and do not preselect it. The acknowledgement needed to respond to a request serves a different purpose from an invitation to receive ongoing promotional messages. Make the wording match the actual data path and avoid promising a response time the team cannot support.

Define idle, validating, submitting, accepted, rejected and temporarily unavailable states. Disable repeated submission only while a request is in progress, show that progress accessibly and protect the backend from duplicates. Display success only after durable acceptance. If the record is saved but an owner notification fails, keep it in a visible queue for staff rather than telling the visitor to submit again and creating a second inquiry.

Run this end-to-end submission test

Use clearly labelled sample data and a contact method controlled by the team. Inspect the stored record and staff workflow, not only the page message. Repeat the test with a keyboard, a narrow screen and browser zoom. Avoid putting names, email addresses, phone numbers or free-text answers into analytics events.

• Submit the shortest valid inquiry and confirm every required field has a documented purpose.
• Leave each required field blank, enter an invalid format and verify that the message identifies the field and correction.
• Test labels, groups, instructions, error summary, focus order, zoom and keyboard operation.
• Retry during submission and refresh after acceptance; confirm that one intended inquiry creates one durable record.
• Interrupt the notification path and confirm staff can still find and act on the accepted inquiry.
• Verify privacy wording, retention ownership and any separate optional marketing choice.
• Check that the success state gives a reference, realistic next step and alternative contact route when appropriate.