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?

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 accessible 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.

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.

Crafting questions

Only ask for information you definitely need.

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.

Form validation

Avoid default validation, don’t disable buttons and don’t validate as the user types.

Validate the form when it’s submitted. Server side first. Optionally enhance with JavaScript.

Be tolerant of mistakes like extra spaces.

Show errors at the top of the page. When the user clicks on an error, focus the input.

Put each error just above the input 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’.

Flow and order

Start with one thing per page. Then put the questions in a sensible order. For example, in a checkout flow, put payment after delivery.

Start without a progress indicator. They’re often not noticed and can be tricky to design for dynamic flows.

In long forms, let users save their progress and return to finish it later. Consider using the task list pattern.

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.

Let users check their answers and make changes to keeps users in control.

After completion, 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

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 a character count 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 touch devices it’ll provide a dedicated keyboard.

Learn when and when not to use the number input.

Don’t mix up radio buttons and checkboxes. Remember you can include more than 7 options.

Select boxes should be a last resort because they’re really hard to use.

Don’t use datalist as 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

If you like this, you’ll probably like Form Design Mastery.