I have worked with web forms quite a lot at this point of my career. To raise handling them to the next level, I want to deep dive into their principles. How does one design a good web form and how to accurately test them to allow security and a good user experience.
This will be a multi part post as I work myself through all the articles about this. First will be the initial design of a web form. Even before writing the first line of code decisions have to be made.
Resources
As always, here are some articles I find useful. Feel free to recommend some in the comments, I will love to expand this list.
“Forms Testing: What It Is and How to Do It” (byRebecca Riserbato) gives an excellent overview about the different themes to take care of. I got most of my points from here.
46 Form Design Best Practices (by Aytekin Tank) is a detailed article about web design and how to create forms that users are more likely to fill. It contains many links to psychological and statistic research.
Or start with “7 Secrets for Designing Great Forms” (by Carrie Cousins) to get a grasp at the most important aspects, as well as “Form Design: 13 Empirically Backed Best Practices” (by Alex Birkett).
Layout
This is especially true for large forms. Group the fields by their content (i.e. address, payment), use headlines, dividers and multiple steps to feed the user bite sized chunks of your form. When using more than one page, make sure to display some kind of progress bar.
If possible, use only one field per line and dropdown as a last resort.
Please read the great articles linked under resources for further hints, tipps and tricks.
Colors
As well as the website as a whole, a form should be visually pleasing. There is a great deal of color theory about which colors are good for this job. Pick up your sites theme and take care about some other details.
Do not use light or unusual colors for your text and controls. Accessibility is key. Use something like WhoCanUse.com to check the contrast between background and text color.
When displaying errors at fields, don’t rely on a colored border, but always display an additional text.
Mobile first
Pretty please take care on how your form will look on mobile. This means using responsive design, but also to test on real devices to see how much space the keyboard uses or wether autofill and autocomplete work as expected. Some browsers and tools are able to emulate the smaller display sizes of smartphones but using a real device will include some unexpected use cases (talking from experience here).
Mobile browsers have different standards (and bugs) than desktop ones and keep in mind, that a phone can switch from landscape to portrait mode.
Field Types and Validators
Even HTML is able to differ between types of input fields. They can be text, numbers or email – and these types should definitely be used. Again, think about mobile devices, where the user should be given a number block when entering his card number instead of using the keyboard.
Often overlooked is the naming of fields in HTML. Aside from syntactic reasons, autofill functionalities will only work, if the email-field is named “email” (using the id and/or name property of the input tag). On that topic, labels should be as short and self-explaining as possible. Use info-icons to reveal additional information inside a popup.
Then there are placeholder and pre-filled fields that help the user select the correct answer.
All frameworks contain some kind of validators for form fields. From checking the format of an email address, the correct length of a number or the information from several fields that in combination have this specific condition and so on. Use validators sparingly; make only the fields required, that are really required (this is also a question of privacy) and check side effects on every constraint for length (i.e. for names).
When applying a complicated validator, the user should be informed about it. This is relevant for password selection, where the rules might sometimes be puzzling.
Navigation
When featuring several fields, a web form should receive its own page context. Best is to include a short welcome page, introducing the form, what it’s about and how long the user might need to submit it. After successfully sending the form, there has to be a notification, via email and success page.
When parts of a form are optional, it’s best to only display them, when they are relevant.
Further Design Principles
- Use easy to understand language to communicate questions and errors.
- Take care of the tabulator order for easy access.
- …
Let me know if there are fundamental design cases I overlooked. Please read the linked articles for more and detailed lists of tipps and pitfalls when designing web forms.
Checklist
- The color contrast between background and text is high enough to allow full accessibility (input fields and labels)
- Fields are grouped by theme and distributed across several pages, if needed.
- Fields are correctly declared with id, name, label, placeholder, info-button and tab order.
- Validation is added by using field types and as much validators as needed.
- Errors are shown inline with a clear message to the user.
- The form is framed with welcome, success and visible progress display.
- Responsive design is important to allow mobile devices.
- Constraints between fields (concerning validity and visibility) are clearly defined beforehand.