Start with the receiving workflow
Ask the receiving team what they need to make the next decision. A reply address and a short description may be essential. Budget, company size, and detailed timing may be useful later without being necessary for the initial response.
Review a sample of past inquiries. Which missing details genuinely prevented a reply? Which fields were routinely guessed or filled with placeholders? That evidence is more useful than copying the fields from another company’s form.
Make effort and outcomes clear
Label optional fields explicitly and explain unusual requests beside the field. Give the message area a prompt that helps a person begin without forcing them to write a formal specification.
Use visible labels associated with their controls; a placeholder disappears when someone types. W3C’s form-label guidance explains the relationship between labels and inputs. Beyond that baseline, read the form as a conversation: does each question earn its place, and does the person know what will happen after submitting? W3C form-label guidance.
Handle failure without wasting the message
Preserve entered information when the request fails. Tell the person whether the submission was confirmed or whether they should retry. If the system retries delivery internally, design the interface and backend together so uncertainty does not produce multiple inquiries.
After success, show a clear confirmation and the reply address used. A reference number can help if the person needs to follow up. Keep the promise modest and accurate: avoid a response-time guarantee unless the team can consistently support it.
Review the complete process, including the notification received by the team. A simple form still fails its purpose if the message arrives without useful context or nobody owns the next step.
Define what each field is for.
A form field should have a purpose after submission. Write down who uses it, whether it is needed to respond, and what happens if it is missing. For a first software inquiry, a useful starting contract might look like this:
| Field | Required? | Reason |
|---|---|---|
| Reply email | Yes | The receiving team needs a route to answer. |
| Project description | Yes | Enough context to understand the requested conversation. |
| Name | Optional | Helpful for addressing the person, but not necessary to accept an inquiry. |
| Company | Optional | Provides context without excluding someone exploring a new venture. |
| Timing | Optional | Useful if known; uncertainty should be an acceptable answer. |
Do not collect a detailed budget breakdown merely because it might be interesting later. If a field changes how the inquiry is handled, explain the choices. If nobody uses a field, remove it. Revisit the contract with the receiving team after real inquiries reveal what context is consistently missing.
Keep the label, hint, and error connected.
W3C’s guidance on labeling controls explains the relationship between a label and its input. In this minimal HTML example, the label remains visible while the person types, and supporting text is associated with the field.
<label for="reply-email">Reply email</label>
<p id="reply-hint">Where should we reply?</p>
<input id="reply-email" name="email"
type="email" autocomplete="email" required
aria-describedby="reply-hint">When validation fails, add a specific error message and connect it to the control as well. Mark the invalid field, preserve the entered values, and provide a clear way to find the error. Native email validation can help with input shape, but the server still has to validate the request and handle mail delivery separately.
Test the complete interaction with a keyboard, a narrow screen, and a failed submission. A disabled button must not become a permanent dead end after a network error. The confirmation should reflect the application’s actual state: an inquiry can be durably received even when its email notification needs retrying. Keep that distinction in the backend and in the words the visitor sees.
A practical example.
For a software inquiry, the team may need a name, reply address, and a short description of the work. A company name, budget range, or target date can be useful without necessarily being required for the first conversation.
Walk through the form as someone who is still exploring the problem. They may know the workflow is broken without knowing what technology or budget is appropriate. Offer an honest “not decided” route for optional choices, and explain what will happen after submission. On failure, preserve entered text and identify the field or service issue clearly. A successful response should confirm receipt without promising a reply time the business has not committed to deliver.
Put it into practice.
- Require a field only when the receiving team needs it to act.
- Use persistent labels and explain ambiguous choices in plain language.
- Test validation, keyboard use, slow submission, and recovery after a failed request.