An enquiry form is a small application inside a website. It collects information, validates it, sends it somewhere, and tells the visitor what happened. A visually attractive form can still fail if labels disappear, errors are unclear, or a success message appears before the request is accepted. Good form design combines readable content, accessible interaction, and a reliable submission contract.
This guide develops a fictional course enquiry form. The example does not submit any real enquiries. Its objective is to help designers specify the fields, states, and checks that developers need. The result should work for keyboard users, people using assistive technology, mobile visitors, and people who encounter an unreliable connection.
Start with the follow-up process
Ask the team receiving enquiries what information it needs to respond. Every field should have a purpose at this stage. A name, preferred contact method, and subject of interest may be sufficient for an initial conversation. Detailed personal history may be unnecessary and can make the form harder to complete.
Record which fields are required and why. Do not mark everything required merely because a spreadsheet contains matching columns. Optional information can be requested later when it becomes relevant. The form should explain the next step, including whether a visitor should expect an email, a telephone call, or another response.
Use persistent labels
Provide a visible label associated with each control. Placeholder text can illustrate a format, but it should not replace the label because it disappears during entry and may be difficult to read. A visitor returning to a partially completed form should still know what every value represents.
Use familiar wording. Preferred contact number is clearer than a vague identifier label if the field is genuinely asking for a telephone number. Avoid abbreviations that only the internal team understands. When the label needs explanation, place brief help text near the control and associate it appropriately in the implementation.
Choose controls that match the data
Use suitable input types, autocomplete purposes, and input hints where appropriate. A telephone number is not an arithmetic quantity, so a numeric control may create the wrong constraints. An email field can support useful browser behaviour, but client-side syntax checking does not prove that the address exists or belongs to the visitor.
Use a select control only when the available choices are defined and manageable. A long list of loosely related courses may need grouping or a simpler enquiry path. Avoid forcing people to select an inaccurate option merely to continue. Provide an appropriate way to express uncertainty when the business can handle it.
Explain requirements before errors occur
If a field has a length limit or specific expected format, state it before submission. Avoid unnecessarily strict rules for names and addresses. Real names can contain spaces, punctuation, and characters beyond a small alphabet. Validation should protect the application’s requirements without rejecting legitimate users because their data differs from a narrow example.
Distinguish required information from preferred formatting. A phone display convention may be normalised after submission rather than enforced through an obscure error. Where regional assumptions are necessary, make them visible. The user should not have to discover a hidden country-code rule through repeated failures.
Design useful error messages
An error should identify the affected field and explain how to correct it. Something went wrong is rarely enough for a missing course selection or malformed email address. Keep the message near the control and ensure the association is available to assistive technology. Do not communicate error status through colour alone.
For multiple errors, provide an organised summary where appropriate and help the user reach the relevant fields. Preserve entered values so correction does not require starting over. Avoid moving focus unexpectedly while a person is typing. Error handling should reduce the work needed to complete the form.
Validate on the server as well
Client-side validation improves feedback, but the server must independently enforce the input contract and security checks. MDN’s form validation guidance explains this distinction. A request can reach the server without passing through the browser interface, so browser checks cannot be the sole protection.
Design the server response states with the developer. The interface should distinguish validation failure, temporary service failure, and accepted submission. Avoid leaking internal error details to the visitor. Provide a useful recovery path, such as trying again later or using an approved alternative contact method.
Make submission status truthful
Show a pending state while the request is in progress. The form should not announce success immediately after a button click if delivery is still uncertain. On confirmed acceptance, show a clear message explaining what was received and what happens next. If a reference number exists, display it without exposing internal identifiers unnecessarily.
Prevent accidental repeated actions, but do not rely only on disabling the button. The server may need a deduplication or idempotency strategy for repeated requests, depending on the workflow. If a timeout leaves the result uncertain, avoid telling the visitor definitively that nothing was received unless the system can establish that.
Test keyboard and mobile use
Complete the form using only the keyboard. Confirm a logical focus order, visible focus indicators, and access to every control and error. Labels, instructions, and messages should remain understandable when the page is zoomed or displayed on a narrow screen. A desktop screenshot cannot establish these properties.
On mobile, inspect the keyboard shown for each field and whether sticky elements cover the submit button or error message. Test long labels and longer entered values. Avoid fixed widths that push controls outside the viewport. Useful spacing matters more than squeezing the entire form into one screen.
Keep the form lightweight
A simple enquiry form usually does not need a large interface framework or several animation libraries. Prefer native controls and focused enhancement when they meet the requirements. Audit third-party widgets because they can add requests, delay interaction, and introduce privacy considerations. Every dependency should have a clear purpose and owner.
Measure the page with the form present, including pending and error states. A lightweight initial display is not sufficient if opening a control downloads a large dependency. Preserve usability when optional enhancements fail. Performance and accessibility often benefit from the same decision to keep the basic workflow simple.
Build a complete test matrix
Include empty required fields, valid input, long input, unusual but legitimate names, invalid contact formats, a slow response, a server rejection, and a repeated click. Use synthetic data and an approved test endpoint. Confirm that no test enquiry is accidentally routed to a real sales queue without prior arrangement.
For each case, record expected feedback and actual behaviour. Check the receiving system as well as the browser when authorized. A success message with no stored enquiry is a functional defect; a stored enquiry with a failure message can cause duplicates and user confusion. Both sides of the workflow matter.
Portfolio deliverable
Create a form specification with field purposes, required status, labels, help text, validation rules, response states, and accessibility notes. Add a prototype using synthetic data and a test report. Clearly distinguish a visual prototype from a working integration so reviewers understand what was implemented.
Frequently asked questions
Is placeholder text enough as a label?
No. Use a persistent associated label. Placeholder text can support an example, but it should not carry essential instructions by itself.
Does a browser email check prove an address is valid?
It checks a format, not ownership or deliverability. The wider workflow must decide whether verification is needed.
Should a form clear after any response?
No. Preserve values after errors and uncertain outcomes where appropriate. Clear the form only when the designed workflow supports it and the visitor has a truthful completion message.