Form elements are ubiquitous and used throughout the site, from member profiles to discussion threads and course quizzes. Good, consistent form design based on accessibility and usability principles help ensure pleasant form-filling experiences.
Less is More
For forms, less is better. Reduce or eliminate unneeded forms, because more form fields will reduce the completion rate.
- Remove as many optional fields as possible.
- Mark all optional fields by adding “(optional)” at the end of the field label. This also makes it clear to the designer when a form has too many optional fields.
- Always explain why we ask for sensitive information, such as a person’s phone number or address.
Facilitate Data Input
In most cases, data input is a chore. Help users by making it a faster and easier process.
- Show hint text within a field for potentially confusing or complex fields.
- Don’t show hint text for simple fields—e.g. name—because it may come across as condescending.
- Use geo-location or postcode lookup services to help fill in addresses.
- Whenever possible, don’t split a field up. For instance, ask for “Full name” rather than “First name” and “Last name”.
- Include the proper input type markup so that the right mobile keyboard is shown.
- Don’t show a “Clear field” or “Cancel” button on a form because it will reset all fields. The user can close the window or go to the previous page if they want to abandon the form.
- On password fields, allow users to toggle the visibility of the password they enter.
- Whenever possible, use frontend form validation. This allows timely error messages to be shown as the user is filling a form up, rather than after the form is submitted.
- Trigger frontend validation only 700ms after a user has stopped typing, or after the user moves to another field. This
- prevents overzealous error messages from appearing as the user is typing.
- Use backend form validation as a last resort, when frontend validation is not possible or feasible.
- Show error messages at the field with the error.
- Error messages should sound human. They should be clear and jargon-free.
- Never blame the user for an error.