Form Architecture

Group by decision, not by data type

Most form grouping errors come from grouping fields by their data type (all text fields together, all select fields together) rather than by the decision they represent. Group fields by the question the user is answering. A shipping address group and a billing address group both contain the same field types but represent different decisions.

Label placement

Top-aligned labels outperform left-aligned labels on completion rate across almost all tested form contexts. The single exception is long, narrow forms on desktop where left alignment allows more vertical scanning. For mobile and standard web forms, use top-aligned labels. Never use placeholder text as a label substitute — it disappears on input and fails users with memory or attention challenges.

Validation timing

Validate on blur (when the user leaves a field), not on input (as they type). On-input validation generates errors before the user has finished forming their answer. On-submit validation forces the user to re-traverse the form. On-blur validation is the correct timing for most fields. The exception is password confirmation fields, which benefit from on-input comparison once both fields have been touched.

Error states

Error messages must be specific, not generic. 'This field is required' is not an error message — it is a constraint restatement. 'Enter your email address' tells the user what to do. Position error messages immediately adjacent to the field that contains the error, not at the top of the form. Use both colour and an icon to communicate error state — do not rely on colour alone.

Multi-step forms

For forms longer than seven fields, consider a multi-step structure. Each step should have a single decision focus. Show progress clearly — a step indicator that shows total steps (not just current position) reduces abandonment. Allow backward navigation without data loss. Validate each step before advancing.