Ask only what the first conversation needs
Begin with the details required to reply and understand the request. Make optional information visibly optional. A budget range can help a discussion, but forcing a choice may cause someone to guess or abandon the form. Explain why an unusual field is needed instead of making visitors infer how the information will be used.
Keep labels and instructions available
Use persistent labels rather than relying on placeholder text that disappears when someone types. Group related fields and use suitable input types and autocomplete attributes. Give an example where a format is unfamiliar. Ensure the layout remains understandable on a narrow screen and when browser zoom increases the size of the content.
Make errors specific and recoverable
Identify the field with the problem, explain what to change and preserve the rest of the entered information. Move focus appropriately when submission fails, without unexpectedly moving it during ordinary typing. Do not rely on red colour alone. Distinguish a validation problem from a sending failure so the visitor knows whether to edit or retry.
Explain the sending step
Tell visitors whether the form prepares a message, submits it to a server or opens another application. Prevent accidental repeated submissions while a request is processing. Show a confirmation only for the outcome actually observed, and retain a direct contact alternative. Test with a keyboard, a small screen and an unavailable sending service before release.
Your practical checklist
- Limit required fields to a useful first enquiry
- Keep labels and instructions visible
- Preserve input and explain errors
- Distinguish preparation, sending and confirmation
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK