Viewers: in countries Watching now:
In this course, interaction designer Luke Wroblewski shows how to create web forms that encourage visitors to enter information and covers ways to capture input without the use of forms. The course covers boosting conversion rates and customer satisfaction, organizing the structure of forms, aligning and grouping form elements, assigning the correct input field types, validating input, and handling data entry errors. The last chapter highlights alternatives to static forms, such as using dynamic inline forms, using web services, and leveraging device capabilities, which can be used to gather additional information or replace a traditional form altogether.
Web forms are basically a series of questions, and how we ask those questions generally falls on labels. Labels inside of a Web form queue up the information we need from people. The way we ask those questions and the way we lay those questions out is often a topic of a lot of debate, in particular, label alignment. Let's jump back to that Boingo get online form that I talked about much earlier. Here, the way we're being asked every question is with a little gray label underneath the input field.
Now, bottom-aligned labels tend to be a bad idea because it's not clear upfront what question we're being asked. Remember in the past the completion is people start from the top and make their way down, question; ability to answer it; question; ability to answer it. It works a bit better than answer; question. Not really how we naturally work. So what are our other options? Well, if we rule out bottom-aligned labels for these reasons, we are left with top-aligned, left-aligned, and right-aligned labels.
Let's take a look at each one, and the advantages of each. Left-aligned labels, as you can see in the image on the left, are where we use the left edge of the labels for alignment and then place the corresponding input fields to which the label applies, in its own column to the right. Now when data is required that's unfamiliar to people, in other words, they really need to think about or process these fields, or more likely, dig up one or two things that they need to answer, a left-aligned solution can actually work well.
The reason for this is it's quite easy to scan the labels on the left. Just go down the list, pick out the one you're interested in, and answer it. Why this works when the data is required is unfamiliar to you is you can take a real quick pass through those labels, see what's in there, and decide whether or not you can actually answer the questions, or whether you need to go get some information or ask someone before you can proceed. When we're asking people for information they're likely to have answers to instantly, like their payment information, home address, phone number, then they probably don't need to scan through what's required, they could just jump right into answering.
One of the problems with left-aligned input fields is that the association between the label and the input field is not as great as it could be. Meaning it takes a little bit to look at the label, then look to the right of the input field and make a correlation between them. It's not that people can't do this. They're actually quite good at it. The problem is it takes them a little while. So forms with left-aligned labels tend to be a little slower to complete. We've seen this in small testing and also in large-scale A/B testing on big sites. When we just swap the labels between let's say left-aligned labels and top-aligned labels, the left-aligned labels force people to slow down and take their time a bit more.
In some cases, this can really be good, like when we want them to consider every input. When we're asking for familiar information, and we want people to get through that form as possible, slowing them down with label alignment is probably not a good idea. One more advantage of left-aligned labels though is that they require less vertical space on a form. Meaning, we don't need to fill up a Web page with a label; input field; label input field; label input field, like we do with top-aligned labels. Instead, each of those sections has their own column thereby making the page a bit shorter.
Now let's look at an example of left-aligned labels in action. Here they're applied to an Advanced Settings dialog, perfect use case for scanning through a list of labels and pulling out the exact field that you need to actually change or modify. In this case, maybe I want to change only the Share Book Field. I look through those labels and really quickly I know which one applies. Right-aligned labels have a bit of a clear association between the label input field. Because the label is right-aligned and the input fields are left-aligned, they're much closer in proximity.
This means it takes a lot less visual effort to align those two things. Now again, with left-aligned labels people can make that association no problem, it just takes them a little bit longer to do so. Right-aligned labels also don't require a lot of vertical space on a page because they again, have separate columns for the labels and input fields. However, with right-aligned labels, it's a lot more difficult to actually scan that column of labels because of this rag that you see in the image here. Jumping between this variety of text makes it harder to read through and actually find what's going on.
However, in a study that I'll get into a bit more detail on in a second, when we compared left-aligned labels to right- aligned labels, we did reduce overall form completion times by nearly half, which is a pretty big deal. So as an example of right-aligned labels, here we see a field asking for your First Name, Last Name, Email, User Name and once again, right-aligned labels right next to those input fields make for a close proximity between the question we're asking people and where they need to answer that question. Top-aligned labels, as it turns out, actually have a lot more advantages and for this reason, I tend to bias myself towards using top-aligned labels when laying out Web forms.
Now before you jump to conclusions, let me explain myself. In the testing we've seen, I mentioned that right-aligned labels cut form completion times down by nearly half. Top-aligned labels cut that even further. So they're much faster than left- aligned labels and faster even than right-aligned labels. When you're asking people for data they're likely to be familiar with and you just want the form to get out of the way, guess what, those seconds actually matter. Fast completion times help people buy something, register for a service, provide the information you need, and get that form out of their way. That's great.
But there's other advantages to top-aligned labels as well. One is flexibility for localization and complex inputs. When you're dealing with a two-column system and also do you translate your English text to a language like French or Dutch, the line length can actually get substantially longer, sometimes even twice as long. When you have more complex inputs like a series of radio buttons or checkboxes, a label above that group of inputs tends to work better to bound the questions you're asking people than a label off to the left on the screen, so top-aligned labels in terms of flexibility for localization and complex inputs, also have advantages.
Top-aligned labels are also easier to code. Frankly, all you need to do is label input field, label input field inside of your markup. No fancy CSS floats or table layouts. It's much easier just to go and render the form as is described in markup. This usually makes it a bit more accessible as well. Though you can manage things with tab index, label and input field tends to be the simplest and easiest for the widest variety of devices to use. And speaking of devices, as we increasingly use more and more small screens and mobile devices to get online and access content and fill out Web forms, a top-aligned label fits nice and snug into a small screen that doesn't have much opportunity for a left-aligned or right-aligned column of just labels.
Now the disadvantage of course for top- aligned labels is that they do require more vertical space. In other words, we're stacking a label on top of an input field, on top of a label, on top of an input field, and that adds up vertically. But personally I like to think about that as an incentive to make your forms even shorter. And as we saw earlier with form length, making your form shorter is a great way to increase conversion and get people through these processes down to the other side of the thing that they actually want. Now let's look at an example of a top- aligned form, and you can see here we've got this nice path to completion, label above input field, leading you to a real big button at the bottom that signals I'm done.
Now because the topic of label alignment, top, left, or right-aligned tends to be a little bit contentious. I think it's worth actually digging into the data that supports why some of these things are faster than others. In some eye tracking and usability studies that Matteo Penzo did a few years back, we can start to see some of the causes. Looking at the left-aligned labels at the top there, you can see things it takes a couple eye saccades or movements to make this association between the input field and the label. When you look at the top-aligned labels on the bottom, people are able to take in the label and the input field in a single eye glance and you see this in the data.
From left-aligned labels to right- aligned labels, the number of overall eye fixations were cut nearly in half. At the same time, form completion times were cut nearly in half. Odds are, there is a good correlation between the amount of visual effort it takes to parse the form and how long it actually takes to complete it. Top-aligned labels made things even faster. Once again, there is a lot less visual effort needed to determine what question was being asked and how to answer it because the label was stacked right on top of the input field. So people were able to get through top-aligned labels much faster.
Now I mentioned there was another advantage to top-aligned labels, and again, because people tend to discuss this topic a lot, I think it's worth diving into a bit more detail. This is the increased use of mobile. So, when you look at what happens to a typical Web form on a mobile device, in mobile operating system that has any amount of decent design in it will try to make things better for you. What do I mean by that? Well, here's a desktop form on the iPhone. When I tap that field to actually access it, it does this thing called Field Zoom, which is it zooms into that field so you can actually see it in a bigger state on a smaller screen.
In other words, you can see the question you're being asked and how you're answering it. There's also a nice little Form Helper on the right that allows you to move between the previous and next fields, auto-fill a form, and click Done. A common theme that will keep coming back to on mobile devices is any little detail that we can do to make input easier, faster, and more accurate goes a really long way on mobile. Now let's take a look at what happens when a form encounters Field Zoom but uses left-aligned labels.
So this registration form on Google has left-aligned labels and once again, I tap in the operating system on the mobile device, it tries to do the right thing by zooming in and giving me more room, but the label is gone. It's off to the left in a separate column and the result, I'm left with asking myself what's the question I'm trying to answer here. No label, no idea. Similar thing happens on Android devices. Once again, you tap on that input field, you have Field Zoom, and the question is gone.
So to reiterate why I think increasingly the top-aligned labels make more sense. we'll begin to live more on a cross- device world where people will access content not just through their desktop or laptop at home, but through the smartphone or mobile device or tablet that they happen to have closest to them. That means thinking about how our form layouts work across all these devices with varying screen sizes, especially smaller screen sizes. Once again, top-aligned labels are a better format for mobile. As we can see here in the Twitter sign up screen, when I tap into my full name and start entering it, the label is clearly present as is help text, as is the keyboard.
Much better formatted for a small a screen device. Now you may be thinking what about labels within input fields. If the big disadvantage of top-aligned labels is screen real estate and want to make things tighter, wouldn't it actually make sense to put those labels inside the input field, that is, combine the question we're asking with where people can answer it. And at the surface, sure, this makes sense. So if we take our Boingo, get online, redesign a Web form on the left, and transfer all of those labels except for the section headers into the input fields, you can see we get a substantially shorter form.
So on a site like LinkedIn, there is a label inside input field that says Write a personal note to all the recipients you have selected for this invitation, and a button to send invitation. I find my inbox sometimes contains messages that say hey, Write a personal note to all the recipients you have selected. This is a case where the label actually became the answer and when pages don't load or aren't coded necessarily perfectly, something like this can happen. I'm sure many of you have encountered the situation when you try and run a search, and the label search inside the input field all of a sudden becomes part of your search, same issue at play.
The other challenge with labels within input fields, and I've seen this in many instances of usability testing, is that people get confused whether the label is actually an answer. They quickly look at the form, see something is inside the input field, then assume, hey, it's done, I don't need to fill this in. That's why it's really important when you put labels inside of input fields or even help text inside of input fields to differentiate it strongly from what looks like an answer. So what you see on the left here is the gray text with a ... at the end, trying to not look like an answer and it's also why on the right you see drop-down menus put these little dash (--) marks before and after a value that says select or pick one, making really clear that isn't actually a selected value, it is a label or instruction for you.
Third point around labels within input fields to recognize is that when you actually tab in like here on the threadsy sign up sheet, the label that was in the input field usually by default is gone. So what question am I answering, and let's say I hit Tab...now what is this form even asking me about? A little side note, these things don't really look like input fields anymore. This is usually why it's better to stick with the forms, it doesn't mean that looks like an input field instead of black boxes because encountering this, I'm not entirely sure what I should be doing.
This issue isn't so bad on a small form where it's just asking you for your username and password, but imagine an entire form where every time you answer a question, the label is gone. It makes it pretty hard to go back and check your work because you don't know the questions you were actually answering. All you see are your answers. Now there are situations where labels within input fields can make a lot of sense and this tends to be where we have node input groupings and structures. On the Apple Checkout form you see that they're asking for a shipping contact and shipping address.
The structure of a shipping address is pretty common to most people. In fact, I've observed through eye tracking data when people encounter an address block, they tend to not even really look at the screen anymore and just start entering all the pieces of their address. They know how it's structured and it's clear well how the pieces add up. So on Apple's form, labels within input fields have been used in these blocks, but note they're still a grouping label, in other words shipping address, so that you know the information you entered is about shipping. The structure of the inputs makes it clear it's an address, but how that address is used still relies on this grouping label.
Let's look one more second at the default behavior we get inside of Web browsers. As I mentioned before that on mobile in particular, labels within input fields can really help you condense your form and get more information on the screen, but if you use the standard HTML5 placeholder attribute, it's been specified to include tips and help text inside of an input field, not labels. So the default behavior is, when you tab in, the label is gone.
Now this isn't how things work in native operating systems on most mobile devices. In fact, on the same device of the iPhone, when you use an application like Mail to set up your account and you tap into an input field, the label stays there. This is the default behavior in the operating system. It's not the default behavior in Web browsers and this is common across not just iOS, but also Android and even BlackBerry. So hopefully this behavior makes its way to the Web browser at some point, but clearly it's valuable on mobile devices since every native operating system is using it.
It's debatable whether this has actually enough contrast to convince people it's not an answer, especially on a longer form, but at least the effort is there to really distinguish what's been completed by you and what still remains. Apple has done a similar thing again programmatically in the Web browser for their sign in to checkout. On the Apple Store when you mouse in or tab in to the input field asking you for your iTunes or Apple ID, they're keeping the label there until you actually start entering in a value, getting around this issue of labels disappearing as soon as you start interacting with a field.
So while labels within input fields hold a lot of promise, there's a couple things to take into account and use as a basis for decision about whether or not you should go ahead and do labels within input fields. Number one is you need to be really vigilant about that label not becoming part of someone's answer. As we saw in the search example I discussed in the LinkedIn invitation, when a label becomes part of your answer, things can get pretty hairy. Two, it's really difficult for people to discern what's an answer and what's a label when those two things look really similar.
So it takes a lot of effort to make sure that labels really look different than the answers you're providing in a form. And last but not least, consider when somebody starts answering a question or when they've completed filling in a question, that question in the form of a label is gone when you place it inside the input field. All these things together add up to a number of considerations that may or may not make labels within input right for you. To wrap up label alignment in general, overall, I find myself and the recommendations I'm making to others to lean towards top-aligned labels.
If you're dealing with familiar input and your goal is to get people through a form, which is very often our primary objective, top-aligned labels allow you to get through that form quickly, have advantages of coding, layout, and work across lots of different devices. If you're under really tight vertical constraints and you still need some of that speed, you might consider right- aligned labels, but you'll have some disadvantages especially on smaller screen devices. If you're dealing with really unfamiliar advanced data entry where you want people to really slow down or pick out a label from a list, left-aligned labels could be the way to go, but again, increasingly in our multi-device world, that may be outweighed by the advantages of being operable across multiple devices and smaller and smaller screens.
And last but not least, if you're dealing with devices that support labels within input fields, like these native operating systems on iOS, Android, or BlackBerry, by all means use them. If that system has baked in all the different controls that you need to make that solution work, have at it. Sadly, the Web browser isn't there yet, but hopefully in the future it'll get there soon.
There are currently no FAQs about Web Form Design Best Practices.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.