Forms are often built by copying every field in a database table. That makes the team's storage model the visitor's problem. A better starting point is the action that follows submission: which details are needed to reply, quote, ship, or book?
Remove fields before arranging them
For each question, ask who uses the answer and when. If nobody can name a decision it changes, remove it. If the team only needs it later, ask later. Keep optional fields visibly optional and avoid requesting the same detail twice. A contact form usually needs a way to reply and enough context to route the message; a full project specification can wait for a conversation.
Help before the error
Use persistent labels and show format rules before submission. “Work email” is clearer than a blank box with an example address that disappears as soon as someone types. If the answer is invalid, point to the field, explain how to fix it, and preserve everything else the person entered.
Make the outcome clear
The button should say what happens next: “Send enquiry” or “Book a call.” After submission, confirm what was received and when a response is expected, but promise a response time only if the team can meet it. For long forms, test with real people on a phone and keyboard. Friction often shows up there first.
Further reading: W3C WCAG 2.2 quick reference.
