Practical checklist
Five checks to start with
- Map each field to the first useful reply.
- Explain required information and unusual formats.
- Prepare clear error, pending and success messages.
- Test both languages and confirm actual receipt.
- Keep personal message contents out of analytics events.
Design backwards from the first useful reply
Ask the receiving team what they need to respond meaningfully. A design enquiry may require a current website, desired scope and target timing. A product enquiry may require an item reference and destination market. Do not begin with every field the company might eventually want in a customer database.
Write the intended first response alongside the proposed form. If a required field does not affect that response, consider making it optional or asking later. A shorter form is not automatically better; the aim is appropriate effort and enough context to continue the conversation.
Explain fields that need interpretation
W3C guidance supports explicit instructions and understandable feedback. Show labels that remain visible when someone types, identify required fields and explain unusual formats before submission. Avoid relying on placeholder text as the only instruction.
For international enquiries, review assumptions about telephone numbers, addresses and company names. A Hong Kong form that accepts only eight-digit numbers can obstruct an overseas buyer. If a budget is useful, offer an honest “not decided” option when the team can still help; do not force visitors to invent a number to continue.
Prepare errors and success states as part of the content
Write a useful error for each likely failure. “Please enter an email address we can reply to” tells the visitor more than “Invalid input.” Keep entered information when a recoverable error occurs, and make the message easy to find without depending only on a colour change.
The success state should reflect what the system has actually confirmed. If the enquiry has been accepted, explain the next step and only promise a response period the team can support. If the system cannot confirm receipt, provide a clear alternative contact method rather than showing a misleading success message.
Test the whole route in both languages
Use test data and follow the journey on a phone, with the keyboard open, and with keyboard-only navigation on desktop. Try a valid submission, a missing required field, a malformed address and a recoverable connection failure where the system supports that test. Check that a fixed contact button does not cover instructions.
Then confirm receipt, routing and readable subject lines with the intended team. A technically successful request is not enough if it reaches an unattended mailbox. Review the Chinese and English messages together so that required information, confirmation wording and response expectations stay aligned.
Measure steps without collecting message contents
Define contact clicks, accepted submissions and qualified enquiries separately. They represent different stages. Ask the implementer which events are recorded and ensure that free-text messages or personal contact details are not included in analytics events.
Use the results to investigate obstacles rather than assume every incomplete form is a design failure. Some visitors may not yet be ready to enquire. Combine aggregate observations with the receiving team’s feedback, then adjust one field or instruction and review the effect with enough context.
Sources and scope
- W3C: Form instructionsw3.org
Technical reference; examples and review procedures in this article are editorial recommendations.
- W3C: Form notificationsw3.org
Technical reference; examples and review procedures in this article are editorial recommendations.