index.md 12KB
title: Form design: from zero to hero all in one blog post
url: https://adamsilver.io/articles/form-design-from-zero-to-hero-all-in-one-blog-post/
hash_url: ea6f364438
Hi there. If we haven’t met before, I’m Adam and I’m obsessed with designing forms. And I have been for almost 20 years.
What is it about forms then?
Every meaningful interaction on the web is achieved by a form of some sort. Whether it’s letting users renew their passport, send an email or buy something.
Basically anything that isn’t just reading content.
What’s interesting though is that on first glance, forms are easy. In a few minutes you can have text boxes and radio buttons on screen and working.
But look around the internet for a minute, and you’ll find a million and one usability issues revolving around forms.
I’m pretty sure I’ve come across every single one of them. And spent hours solving each one in a way that works for everyone.
And some forms have more than just fields and buttons. They can contain complex interactions or form part of a wider journey—both of which need due care and attention.
So, if I was designing a new form, I’d want to know how to avoid the common issues. And to use my time to solve newer and perhaps more difficult problems.
Seriously, who wants to spend time solving something that’s already been solved?
That’s right—nobody.
A note before we begin
Much of what I’m going to say might sound obvious and boring. But boring is good, we don’t need to over complicate matters.
So if you’re looking for new and innovative ways to design forms, this is not for you.
This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.
This guide is quick and to the point—a whistle stop tour of the knowledge I’ve accrued in my years of form design. It’s not exhaustive, but rather an entry point, designed to save you time on the basics.
Many points I make link off to other articles. If you read each of them, you’ll be more than equipped to make simple and inclusive forms that get out of the user’s way.
Let’s begin.
Don’t mess with labels
Every input needs a label. Sighted users can see them, visually-impaired users can hear them and motor-impaired users can more easily set focus to the related input.
Labels should be placed above the input because this works well for different size content and different screen sizes.
Placeholders are problematic—both as makeshift labels and as a means of storing additional hint text. Instead put hint text below the label and above the input.
Float labels are also problematic. They have many of the same problems that placeholders have—and some of their own.
Seriously, don’t mess with labels.
Crafting questions
You should know exactly why you’re asking every question. Use a question protocol to help you.
Don’t mark required fields, mark optional ones. Or better yet avoid optional questions by using a branching question.
Use hint text to tell users why you’re asking them for certain information—it’s not always obvious.
Hint text should be used where users are more likely to make a mistake, like when having to satisfy a complex set of password rules. Error messages should be a last resort.
Style and microcopy
Form fields should look like form fields. That means they should be bordered and empty so it’s obvious where the input goes. Make fields easy to tap—44px height or more is good.
The width of the field gives users a clue as to the length of the content it requires. So don’t make all fields the same width for aesthetic purposes when you know the expected length.
Avoid multi column form layouts. They’re error prone, slower to use and can cause abandonment.
Buttons should look like buttons. They’re harder to spot when they’re aligned right, especially for screen magnifier users. So position the button to the left and below the last field.
Use sentence case for labels, hints and error messages. It’s easier to read and to spot nouns. Button text should be a simple verb because the user is doing something.
Form validation
Live inline validation is problematic. Turn off HTML5 default validation. Don’t disable buttons—users won’t know how to fix errors without feedback.
Validate forms onsubmit. You can still catch errors with JavaScript to avoid a server-side round trip.
Be tolerant of mistakes like extra whitespace, dashes and slashes. Do the hard work so users don’t have to.
Show an error summary at the top of the page which contains a list of errors. When one is clicked, set focus to the input. For a group of inputs, like radio buttons, set focus to the first input.
The error message should also be placed in context of the field. Put the message just above the field. Placing it below can cause problems.
Prefix the word “Error:” to the document’s title. It’s the first thing announced by screen readers when the page loads.
Style error messages in red and use a warning icon to provide a comparable experience for colour blind users.
Error messages should be concise, specific, use plain language and avoid pleasantries like ‘please’. The GOV.UK Design System is full of brilliant examples.
You can see all of this in action here.
Flow and order
Start with one thing per page. Then put the questions in a sensible order. For example, payment details should come after delivery details.
Start without a progress indicator. They’re often not noticed and can be tricky to design for dynamic flows.
Tell users what they need and how long the form will take to complete before they start.
In really long forms, let users save their progress and return to finish it later. Use the task list pattern to break up the journey into small, manageable parts.
Put back links in the top left of the page so users don’t have to scroll past the form to go back. Avoid putting links within the body of the form as it disrupts the tab sequence for keyboard users.
Just before the end of a transaction, let users check their answers and make changes. This provides reassurance and keeps users in control.
When a transaction is complete, show a confirmation page and send users an email confirmation. Tell users what will happen next.
Now’s a good a time to let your brand shine through. This is the beginning of the relationship—not the end.
Go faster
Design for common circumstances by putting the most used option first and marking it as selected. Except when you need to avoid bias—like in surveys.
Use the browser’s autofill routine to stop users from typing data manually. This also reduces the risk of typos.
Avoid the maxlength attribute. Many users don’t look at the screen as they type, so they won’t notice that some of their keystrokes were ignored until they look up.
Use form validation and a character count component instead.
Use autocapitalize="none", autocorrect="off" and spellcheck="false" to stop browsers automatically changing user input on fields that expect grammatically incorrect data—like email addresses and passwords.
Field design
Use the right input type. On mobile it will provide users with a more useful keyboard.
Learn when and when not to use the number input.
Don’t mix up radio buttons and checkboxes. And remember you can have more than 7 options on a page.
Select boxes should be a last resort because they’re really hard to use. Try radio buttons instead. Or use an autocomplete, if there’s a long list of options.
Don’t use datalist for an autocomplete. It’s buggy and lacks support. Autocompletes are really tricky, so you can use mine.
Use three separate text boxes for dates. Only use a date picker when users need to find a date in relation to another, or if they need to know the day, week or month that the date relates to. Date pickers are tricky, so you can use mine.
Use a stepper component to help users make small numerical adjustments quickly and easily.
Don’t use multiple inputs when one will do, like when asking for a sort code. If you do have multiple inputs for a field, don’t auto tab between them. It causes users to make mistakes.
File uploading: try to accept large files and as many file types as possible. Don’t rely on the multiple attribute. Besides a lack of support, it can only be used to select files from a single directory.
Here’s one accessible way to let users upload multiple files.
The end
So there you are. A few hundred words on how to avoid 90% of the problems found in most online forms.