Form design: from zero to hero all in one blog post
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?
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 accessible forms that get out of the user’s way.
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.
Put labels above the input. This works well with varying content, states, screen sizes and needs fewer eye fixations.
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.
Only ask for information you definitely need. Use a question protocol to help you.
Avoid double-barrelled questions. They’re hard to understand.
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.
Add hint text when 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
Make form fields look like form fields. Apply a border and make sure they start 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.
Make buttons look like buttons. Align them to the left edge of the last input where users naturally look for them which also makes it easier for screen magnifier users.
Use sentence case for labels, hints and error messages. It’s easier to read and spot nouns. Use a verb for button text because the user is doing something.
Avoid default validation, don’t disable buttons and don’t validate as the user types.
Be tolerant of mistakes like extra spaces, dashes and slashes. Do the hard work so users don’t have to.
Put errors in a list at the top of the page. When the user clicks on an error, set focus to the input. For a group of inputs, like radio buttons, set focus to the first input.
Put the error message just above the field too. Placing it below is problematic.
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, put payment details 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.
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.
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.
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.
spellcheck="false" to stop browsers automatically changing user input on fields that expect grammatically incorrect data—like email addresses and passwords.
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.
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.
That’s it. A few hundred words on how to avoid 90% of the problems found in most online forms.
UX that actually works in 3 minutes or less
Join 4000 UXers in my weekly newsletter. Every Sunday morning, you'll get 1 design tip that shuns ‘best practice’ and actually works. Mostly about forms but not always.