Please note that our ad-hoc test setup didn’t resemble real-world conditions. Since I had to properly measure saccadic activity and saccades times, I had to eliminate all elements that would force users to visually browse through the pages we used during testing.
We based our test setup on Luke Wroblewski’s article “Web Application Form Design.” Luke provided valuable insights and feedback during both our test preparation and results analysis. Thank you, Luke! Thus, we were able to subject Luke’s theories to usability testing and enrich them through the power of numeric data.
Champion Advertisement
Continue Reading…
During the process of building the forms that we would test, we tried to respect Luke’s suggestions regarding the relationship between label placement and formatting and the type of form content—well-known data versus unfamiliar data that requires thought. Thus, you’ll find both types of data on each of the pages that we tested. To add some real-world flavor, we paired inputs fields for well-known data with other slightly more difficult form elements such as drop-down list boxes. Moreover, doing so helped us to confirm our previous findings about forms.
Our test subjects comprised both expert users—primarily designers and programmers, but also some usability experts—and novice users. We requested users to complete all of the forms that we presented to them. Our gaze-path recordings were complete once a user clicked the submit button.
Test 1: Left-Aligned Labels to the Left of Input Fields
This was the first case we tested, because it’s the most popular format in use on the Web. Not surprisingly, both classes of users performed very well in associating the label with the proper input field.
For all users, we found that there was a single saccade between the label and the input field, which means that users easily perceived the connection between them. However, a medium saccade duration of 500ms (milliseconds) was typical, which is quite long, showing that users were experiencing heavy cognitive loading.
The whitespace between labels and their input fields worked well in visually guiding the users’ gaze path toward the input fields. In fact, there were no fixations over whitespace. However, excessive distances between some labels and their input fields forced users unnecessarily to take more time to interact visually with the form. Figure 1 shows the eyetracking data for this test.
Figure 1—Testing left-aligned labels to the left of input fields
Since we included a drop-down list box in the form, we also had the opportunity to confirm our previous findings about them: that they are the most eye-catching form elements. When facing a simple form on a white page, the first fixation of all users was on the drop-down list box. This form element clearly conveys its meaning and how a user must interact with it, giving it a higher importance in the user’s mind. Moreover, in our first test form, the item selected in the drop-down list showed just a number, with no reiteration of the meaning the label communicated. We found that most test subjects, including the expert users, were forced to recheck the label to remind themselves of the value of the numbers the drop-down list contained.
Test 2: Right-Aligned Labels to the Left of Input Fields
While the meaning of the labels and their placement to the left of the input fields was exactly as in the previous test, the right alignment of the labels reduced the overall number of fixations by nearly half, showing that this layout greatly reduced the cognitive load required for users to complete the task. Also, the form completion times were cut nearly in half.
There was almost no saccadic activity between the labels and their corresponding input fields, both because users very quickly understood the meaning of the input fields and because of the ease of the lateral eye movement.
While we had 500ms saccades with the left-aligned labels, with right-aligned labels, the saccade times between the labels and the input fields were only about 170ms for expert users and 240ms for novice users.
My initial concern with this particular form design was that it would be difficult for users to make the transition between typing their data into an input field and moving their eyes to the beginning of the next label, because its position was unpredictable. Well, I couldn’t have been more wrong. Their diagonal eye movements were very quick, and there was no need for them to reposition the fovea over the initial word, as the eyetracking data in Figure 2 shows.
Figure 2—Testing right-aligned labels to the left of input fields
Most users—both expert and novice—needed to recheck the input field’s corresponding label in this case, too—though the relative brevity of the saccades made this task slightly simpler than in the previous test.
Test 3: Left-Aligned Labels Above Input Fields
From the results of our second test, we knew that the nearer a label is to its input field, the more quickly users could move from the label to the input field. So, we were not surprised when we noticed that most of the fixations were right on the input fields rather than on the labels, as the eyetracking data in Figure 3 shows.
Placing a label right over its input field permitted users to capture both elements with a single eye movement. Also, if a label indicated data that was very familiar to users—for example, their first name or family name—users did not fixate on the label separately to read it. They were able to view both the label and the input field in the same foveal area; thus eliminating the need for additional fixations and saccades.
Note—For a brief introduction to how human eyes work, take a look at my article “Introduction to Eyetracking.”
Moreover, we measured shorter saccade times of just 50ms in cases where users did move from a label to its input field. Recall that, in the case of left-justified labels, the saccade times were nearly ten times as long. So, users were able to complete the form very quickly and with a reduced cognitive load.
After two test cases in which the drop-down list box proved to be the most prominent form element, I wanted to check whether its position would influence the results. Not at all. Independent of its position, it continued to attract users’ attention. In all cases, we found it to be, indeed, the most eye-catching form element. It’s more prominent than even the submit button.
I’d also like to point out that, in this case, none of the expert users needed to recheck the corresponding label; though some novice users did need to recheck the label.
Test 4: Bold Labels Above Input Fields
I thought this would be more a sub-case than a full-fledged test case, but the differences in the results we obtained led me to see this as a separate case. I had in mind what Luke had said in his article “Visible Narratives: Understanding Visual Organization.”
“In this layout [with labels above the input fields], it’s advisable to use bold fonts for input field labels. This increases their visual weight and brings them to the foreground of the layout.”—Luke Wroblewski
However, bold labels resulted in an almost sixty-percent increase in saccade time to move from the label to the input field—from 50ms without bold labels to 80ms with bold labels—with no apparent advantage from the more prominent labeling. Bold labels were more difficult for users to read and perceive—probably because there was more visual confusion between the bold text and the heavy adjacent borders of the input fields. Figure 4 shows the eyetracking data for this test.
Figure 4—Testing bold labels above input fields
I’ve reviewed these results with Luke, and we’ve agreed that the absence of any visual design on our test pages might have modified the impact of the bold labels. However, as I said at the beginning of this article, what we tested was performance in terms of time, or speed, which required the absence of any other visual noise, and the times we recorded for bold labels were fairly poor.
Conclusions
Some interesting guidelines arose from this brief analysis of our test results. Coupling the following guidelines with Luke Wroblewski’s form design guidelines will help you to build the best form possible in each different situation.
Label position—Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.
Alignment of labels—In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.
Bold labels—Reading bold labels is a little bit more difficult for users, so it’s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.
Drop-down list boxes—Use them with care, because they’re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.
Label placement for drop-down list boxes—To ensure users are immediately aware of what you’re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.
Acknowledgement—I would like to thank Magda Giacintucci, of Consultechnology IMR, for her help, both in preparing the lab setup and conducting the tests.
I really enjoy these articles. Thanks. Most of my feedback on Web forms comes from either people getting things wrong and my tweaking to reduce the errors or from users complaining.
This research using eye tracking and times picks up the subtle advantages one form has over another.
Thanks for your article.
I’d be interested in learning whether long forms should be spread over more than one page or better kept long. What would the optimum form height and length be. for example?
Question: Have you planned on trying to measure this study in comparison to how adding vertical vs. horizontal space effects the overall usability of a form. That is, while the label in the top layout seems great for a small chunk of fields, how would it work for a much larger collection of fields that would probably cause a page to scroll quicker?
Of course, I also realize that it allows for the page to be split in half and possibly doubling the density of fields on the screen.
I guess, I’m trying to figure out the cost/opportunity benefits of this study in a more scaled environment.
Excellent research! I’ve been looking for this type of research finding for years. I’ve been building long Web forms for intensive data collection applications the same way (right align labels for long forms, labels on top for short forms) since 1996. Each time I start a new project, I wonder if maybe I shouldn’t do it another way, but common sense told me to stick to the best practices I’d developed.
It’s great to have validation.
Thanks!
Excellent article and useful information! Thank you. I would like to make one small insignificant correction, however, in your use of the words “left-justified labels.” I am sure you meant “left-aligned labels,” since to left-justify anything is impossible. To justify type means, a : to space (as lines of text) so that the lines come out even at the margin b : to make even by justifying , to align text to both the left and right margins at the same time, which is not what you were talking about or illustrated. Unfortunately, a programmer, who will remain unnamed, misused his dangerous lack of typography knowledge during the WordPerfect era and coined the terms left-justified and right-justified when defining an alignment of text. When I discussed it with him he refused to fix it. I believe he made up those words when he found out that text that is even on both sides, “like newspapers do it,” was called justified. I hope his ignorance back then does not redefine our language now. It has, however, influenced a lot of software today. I just know that it pains me to see someone as intelligent as you get caught in that trap.
It would also be interesting to see how best to apply instructions to a field—for example, showing a user in what format to enter a date or something similar.
Thank you for publishing this study. It’s one of those things that designers always argue about heavy in subjectivism and without any proof. Now there are some study results to back up your claim or rethink your position on this issue.
In my experience label placement has often been determined by how much real estate you have on the page to accommodate the form, or whether you’re trying to get important form elements above the fold. This article has convinced me that any benefits you think you might be achieving by having labels next to a field, and hence condensing the form, might be lost in the time a user takes to complete the form. Thanks for the great article.
One advantage of having field labels left aligned is that the user can scan the form more easily (to assess the time and effort needed to complete it) than if the field labels were right aligned.
Hi
I have a doubt on placing right-aligned labels. What if a design is not fixed and a user resizes the screen? I believe, if a label contains two or three words, it will wrap to the next line. I think it would then be a bit of a problem to read and eyetrack the label.
I think if a form has very few input fields, the problem is less, but if a form contains many input fields, that definitely it is more of a strain to the eyes to scan the labels.
This article is a great resource!
But… Is the result of the research under the effect of the formative evaluation?
Is the selection of different group of user for each test form better than one group over the form?
I find this sort of stuff really interesting, so thanks for the advice. What concerns me is that your forms are not laid out like you have described in this article. They are to the left of the input field, they’re bold, and left aligned. Is there any reason for this?
Not bad. I mean, it sure is great that you finally proved that left-aligned labels are less human-friendly than the above-the-field labels.
However, you’d rather conduct a research how long (5-10 or more) field forms with labels above the fields perform with users. Are they slower due to the sheer vertical size of the form? I’d suspect the absence of a neccessity to move eyes from the field to the label and back will compensate for that, though.
The debate on the placement of labels in forms has been raging for a long time. It’s been a very contentious issue within UX design teams. That’s why I asked Matteo to do this study.
For years, when I’ve been the person responsible for setting guidelines, I favored right-aligned labels over left-aligned labels. However, when I was consulting at Cisco, their UX guidelines required that labels be left aligned, so I just did my best to ensure that the lengths of labels were as similar as possible.
At CHI 2005, I was discussing the issue of label alignment with one of our Advisory Board members, Whitney Quesenbery, who told me that one of her friends had done an eyetracking study that had definitively proven left-aligned labels were preferable. Thus, the left-aligned labels in this comments form. (Matteo isn’t responsible for the design of this site.) I’d really like to see the data from that other study, so I could assess why the findings of the two studies are different.
Note that comments are above input fields in our subscription form. However, minimizing the use of vertical space was more of a concern in our comments form. There are multiple factors to be considered in making design decisions. Now, that we’ve got this great data from Matteo, I’m sure we’ll be switching to right-aligned labels in this form when we can find the time to make changes.
When I was editing Matteo’s article, I raised a few issues regarding things that haven’t really been tested adequately yet:
The impact of placing labels only in drop-down lists on the editability of forms. Once a user selects an item in a list, the label embedded within the list is gone.
The affect of using bold labels to the left of input fields.
The impact of the amount of vertical space between a bold label above an input field.
Label placement in long forms with few required fields. In this case, where users need to skim the labels, should labels be above or to the left of fields?
Also, is the greater time spent reading a bold label truly attributable to users having more difficulty reading the label or just to them actually reading it rather than just skimming it? Bold labels do demand more attention. They also provide opportunities for expressing the hierarchy of information within a form.
Many of you have also pointed out other things that are burning issues for you, so I hope Matteo will further explore some of these issues in future articles.
Matthew
Eyetracking gives a lot of answers, but it’s not the holy grail of usability. Long forms frighten users, so there really has to be a valuable reward in order to motivate users to complete a long form.
Mia
As I pointed out in my article, what I wanted to study was whether one label position was, objectively, better than another. I needed a lot of design purity to correctly measure times.
Richard / Digiguru
LOL, man ;-) UXmatters should probably consider a form redesign after what I’ve written.
Sham / Nashad / Yuri
What we found shows that right alignment doesn’t influence scan times. For longer forms, I’d say that you could correctly use space and separators to ease the scanning process, but it would be interesting to test this with eyetracking.
But… there is a but… we cannot test every form layout/length context: so, my friends, this article showed you some good ways to improve your forms. But it’s a starting point, not the conclusion.
I’ll do my best to recreate a proper test setup in order to give you some more answers, so stay tuned.
PabiniHeheh… You didn’t tell me you already had some answers about forms. :-)
I’ll try to test some of your points in the next setup. However, I don’t think bolding left-aligned labels could in any case improve their effectiveness. But we could probably give it a try.
This is an interesting study, and it’s fascinating to see the eye movements. However, it seems to me that there are at least two built-in factors that may have affected the results.
First, you don’t say whether users always completed the forms in the same order. If they did, starting with form #1 and moving to form #4, then it seems to me part of the speed gain on form #2 could come simply from the fact that they’ve already answered those same questions in form #1, and it wouldn’t take as long to process them a second time.
Second, I note the the labels for forms #1 and #2 are actually longer and harder to read than the labels for form #4. Just glancing at them myself, it takes longer for me to make sense of the labels in the first two forms than it does in the final form. This could easily contribute to the speed gain observed.
Have you thought about these factors and whether they may have played a part in the results you saw?
Thank you for an excellent article.
I’m not sure whether the author, editor, or readers are aware, but there is a great international community of forms designers (paper as well as online) who regularly discuss issues such as these and circulate research. We’re called Business Forms Management Association (BFMA for short), although we are a community for all sorts of forms issues. I highly recommend joining or checking out our free discussion forum called Formspace.
Come visit us at our Clubhouse or have a look at Formspace.
Hey Matteo, I haven’t personally done any studies on form design and never saw the data from the study Whitney’s friend did. Maybe we can get them involved in this very interesting discussion. :-)
I wasn’t suggesting the use of bold to “improve the effectiveness” of left-aligned labels. What I’d like to know is whether there’s any visual interference from bold right-aligned labels to the left of input fields, and what role distance plays in any visual interference that occurs when bold labels are above input fields.
What interests me most though is whether the length of forms affects what formats are most effective.
Jessica—Thanks so much for sharing the BFMA links.
This is a facinating study and seems to be an actual practical use for eyetracking.
However, this doesn’t address (nor was it intended to do so) updating forms such as a user profile or billing information.
Generally, in an update case, a user would be scanning for one bit of information to update. It is in this case that left alignment seems to make the most sense.
Contrast that case to this study, in which a blank form is presented to the user who must complete every field line by line. I can certainly see benefits to right alignment or a stacked position here.
I would be facinated to see a similar study in which users were presented with a pre-populated form and told to update a field halfway down the form such as their phone number.
First of all, Matteo thanks for running this great analysis. It’s very useful. Just wanted to speak to the notable differences between my cumulative data (usability and live to site testing) and Matteo’s findings.
For one, the eyetracking data indicated that top or right-aligned input fields resulted in a lower number of eye fixations and reduced completion times in comparison to left-aligned labels. This maps well to my findings in the usability lab and on live site testing. But because the forms tested in the eyetracking study were short (only four input fields) and all of them were required, a few common scenarios may have been left untested.
When they first encounter an unfamiliar form, users often scan the input field labels to determine if they’ve found the right form and to see if they have access to the information required to complete the form. In this scenario, right-aligned input labels can reduce the effectiveness of scanning to determine what’s required to complete a form, because of the left rag of the text. This is more of an issue in long forms versus short ones and a good example of how context can determine which form layout is right for your application.
Applications with lots of different forms may opt for left-aligned input fields to enable content scanning at the cost of slightly longer completion times. Likewise, long forms with many optional input fields may utilize left-aligned labels to enable users to quickly find the few input fields they actually need to fill in. Editing just one or two fields in a form is a frequent use case and an easily scannable list of input labels can help users quickly find a specific input.
The other key distinction between my cumulative findings and Matteo’s eyetracking analysis was the effectiveness of bold labels in vertically aligned forms. Here again, context is key. When there are more visual elements on a Web page and/or a form is long or contains lots of different inputs (radio buttons, check boxes, multiple drop-down lists), the bold labels work well to separate the form fields. This is especially true with groups of input fields like multiple check boxes or multiple radio buttons.
In Matteo’s study, the bold labels actually began to compete with the form fields for visual attention because they have a more equal visual weight. The normal (non-bold) font contrasted more with the input fields thereby providing a notable distinction between label and field. Whether you use bold labels or not, the key is to provide enough visual contrast between input label and input field to enable scannability and distinction.
Yes, even more follow-up research ideas for you. Another task commonly involving forms is to scan for a specific completed field to read or edit, as opposed to completing each field in succession, as you tested here. I suspect left-side left-aligned labels would perform much better than the other two alternatives in that case.
You also mentioned, “The whitespace between labels and their input fields worked well in visually guiding the users’ gaze path toward the input fields” in the left-left condition, but is that necessarily true? Would adding leaders (as commonly done on dead-tree forms) help or hurt performance in that condition?
soxiam wrote:
It’s one of those things that designers always argue about heavy in subjectivism and without any proof.
This article doesn’t prove anything. It provides very interesting and useful insights into certain design concepts and into certain specific executions, but it’s hardly conclusive.
If, for example, you were to choose to make your field labels not-bold from now on simply because of the slim evidence of this article, well, I think that’s kind of short-sighted. The “it depends” factor is still pretty huge, and the time differences clocked in this article can, in many cases, be seen as almost completely insignificant when compared to other factors like credibility, branding, voice, and more.
If I had to make a choice, for example, between (a) making my constomer-facing Web site sign-up form 50% more efficient according to the clock or (b) ten times as seductive and attractive and trustworthy-looking to the user, I’d almost always go with the latter. I’d do the exact inverse if the form was for a data-entry person to type in paper mail orders a hundred times a day.
I would venture to say, however, that most of the work done by most UI designers falls into the first category, in which many other factors outweigh stopwatch efficiencies: credibility, clarity, branding… actually, look at Peter Morville’s hexagon diagram for some more qualities of UI design that transcend empirical measurement.
I also think that some of the insights herein—such as noticing that the increased whitespace of left-aligned labels causes the user’s eyes to have to work harder—are pretty much common knowledge to graphic designers. Designers still like to align their text left, because it just looks better; when the left edge is not lined up nicely, the page gets an overall sloppy, haphazard look. In the end, designers often choose to sacrifice a little efficiency to make the page look more professional overall.
Finally, as Pabini so tellingly points out, sometimes when one study concludes X another concludes Y (in her case, above, she cites a test which “proves” that form labels should align left, the opposite of one of this article’s conclusions). Choosing which study to give more weight in the context of your own project is part of the job of being a designer, too.
In short, this is useful information, but not to be taken as gospel. And it’s great that you’ve shared a lot of the raw data. I suggest readers use these insights as part of a bigger-picture design strategy that includes many other factors. I’ve been writing a lot about this on my blog lately, so my thinking on this is still fresh out of the oven.
Excellent article. I only have one question: What would happen if you did the same study with users whose languages are read from right to left (Arabic, Hebrew, etcetera)? Because in this case, I suppose, that users were left-to-right readers.
I think left-to-right readers would be comfortable with the left/right-aligned positions of the labels, because they are used to reading in that direction, but I’m not sure what would happen with users that read from right to left.
Though I have been interested in the question of how to align forms for a long time, I don’t think I remember an eyetracking study that definitively proves left-justified labels to be the best.
I do, however, know Caroline Jarret (www.formsthatwork.com), who is an expert on forms and is currently working on a book on this subject. Ginny Redish has also done some work on forms design. I draw on their work, but they should speak for themselves here.
The conclusion that I have drawn from many, many discussions on this topic in various forums is this:
If the form is likely to be unfamiliar to users or if the field labels are likely to be scanned as part of learning the form for the first time, left-aligned labels work better. This is because they are easier to read as a column of text.
If the form is most often used frequently or by experts in its use or if the form is most often read for the content of the fields (not the labels), then right-aligned works well, because it keeps the labels close to the field content.
If the form is being translated, fields above work well, because this position is the most forgiving of variations in word-length in the labels.
The two postions that do not work are to the right and below, for what I hope are fairly obvious reasons.
The overall visual look matters as well. Appearance, or presentation, is one of the three layers of the form in Caroline Jarrett’s model. (The other two are Conversation and Relationship.) For example, if field labels are often accompanied by explanatory text under them, left-aligned labels are called for. If field name lengths vary a lot (and you can’t control the line breaks), right-aligned labels might make the form look cleaner.
On the question of bold/not bold labels, I would only urge designers to look at the form as most users will see it—both on entry and in reviewing it before completion—not just as a blank form. What element should have the most focus? Do the labels overpower the field content?
Excellent article. Adding to some of the previous comments about follow-on studies, I’d be interested in seeing some analysis of the visibility of form input hints and comments—like a date format indicator (dd/mm/yyyy) or “Asterisks (*) indicate required information”. We incorporate such hints into much of our form design, but I’ve yet to see (or be able to test) the usefulness and effectiveness of such user-help tools. Do users see these helpful hints?
If you ever have the inclination (and time), I’d love to see a more detailed presentation of your research data. Variability in the data; variability between and within user groups; measures of statistical significance; etcetera
I wonder about input other than one-line text input fields.
What about text areas, radio buttons, and check boxes?
Are drop-down lists easier to recognize than radio buttons? (multi-select-lines -+- checkboxes)
For example, often you can answer yes or no. What is the best input? For radio buttons, above -+- side by side -+- drop-down list -+- select one line out of two
or a rating 1 to 10 (input field, drop-down list, radio buttons, slider)
What about the grouping of input fields?
Radio buttons and check boxes are difficult to enhance to get the focus. How can you handle this?
How to expose required fields?
Where and how to position which button? (Cancel, Preview, or Submit)
This is a very interesting topic I’d like to hear more about.
Let me thank you all for your comments on this post. (It’s in similar comment-heavy cases that blog/comment systems show their limits.) I’m so sorry for the delay in my reply, but first, I was really busy on my day job and then I was on vacation.
Here we go.
GWG | Michael Zuschlag | Bernd
You’re suggesting interesting subcases. My intend to evaluate all the different form labelling/completion cases suggested in these comments and prepare a lab setup to analyze them.
Michael Zuschlag
I recently read an interesting topic on the IxD Discussion mailing list, in which someone—I don’t remember the name, sorry—wrote something about what I wrote about whitespace. And, just to point this out: Yes, my friend, I’m not a designer. ;-)
Anyway, I wouldn’t use leaders, because they could add visual noise to the form—of which there is already plenty with the horizontal and vertical lines of the input fields.However, in my opinion, dead-tree forms are a somewhat atypical case, so testing them is probably superflous at the moment—at the moment!.
Christopher Fahey
You’re right my friend: I’ve just scraped the surface of the problem. More in-depth studies are needed. I’m open to any collaborations or suggestions. Just write to UXmatters and the crew will forward your messages to my private email address.
Jose Manuel
I’ve never tested those kinds of users, but you can probably google this theme and find some interesting papers. Sorry.
Whitney Quesenbery
I do agree with you when you talk about form scanning. but as you can see, my forms were both kind of simple cases and short, so we haven’t experimented with any sorts of scanning behaviors for novices or experts.
My tests showed that novice users are very insecure when filling out a form, so they repeatedly reread labels, even while they’re typing. In this case, quantitatively speaking, right-aligned labels also work better for them, because they speed up the required reading time, in my opinion.
If you like, we can say that this is more an article on performance times for reading forms, and that’s why design is not present—even though it’s so important. I’d say that it’s almost impossible prepare a general purpose setup when design is involved, because design is not general.
Steve Baty
Mandatory-field indicators in forms are a really interesting case for testing. Thank you for the suggestion! Regarding the rest of your comment, I have to say that, unfortunately, I’m not planning any in-depth studies on the subject at the moment.
Nelson
He-he. :-) You should probably give a read to Pabini’s previous reply here in the comments. ;-)
Thanks, people, for an insightful article and valuable responses. It’s just amazing to see how much we’d love for there to be a guaranteed best approach to labeling form fields, but in the end it all boils down to “it depends” again. :) What an interesting profession IxD is… Though it hasn’t provided a definitive best practice, I still feel wiser having read through all of it!
I second the questions that Bernd has raised, especially an analysis of radio buttons vs. drop-down menus.
I question using the default drop-down value as the label. If a user wanted to double-check his selections, seeing the value does not necessarily let him know the question. Surely this works with the case of an address state, but likely not with a more obscure question/answer pairing.
Of course, I do understand that this was primarily an analysis of speed and practicality over usability.
I’d be interested to know if some kind of horizontal guide—for example, a light dotted line—joining a left-aligned label to its field improves usability at all. In my experience, it is the whitespace between label and field that can cause confusion with users and adding a subtle visual hint seems to have made improvements.
I’d also be interested in further studies on other field types such as check boxes, radio buttons, and text areas.
Very interesting. Now I’m really curious about how fields with label IN it—for example, most search boxes in Vista/Live Apps/IE7—will perform. If the trend indeed continues to apply, shouldn’t that increase usability by a factor of, say, a hundred?
Yeah, I agree; this is very interesting. But why didn’t you use the same label names? In the left- and right-aligned examples—maybe it’s just your illustration images—it says “Your address” while the examples at the bottom are labeled “Address”. Wouldn’t you expect to find that the user has to use a little more cognitive power when “your” is stuck in front of the label? Wouldn’t you want to control for that factor by keeping that consistent?
Anyway….I like this study….just curious mostly….not trying to poke holes in your study. :-)
Alpha Binary—what an interesting nickname. ;-) I’m curious about that kind of analysis, too. My initial hypothesis is that, when you can easily remember the label value, it could be more usable. On the contrary, when the label value is difficult to remember, it could decrease form usability.
Hey, that’s very good news. Especially because arranging labels horizontally with CSS only is a bit complicated.
To Alpha binary—Labels within input fields would no longer be labels. I’m talking about the <label> element. Of course, such labels can or should be overwritten by a user,
and the user may forget the labels once he overwrites them.
Another great read. Where did you get your background information about cognitive loading? “…users were experiencing heavy cognitive loading.”
I wonder why a longer saccade time means heavy cognitive loading? I would like to read more about this. Is it that someone is processing the information, trying to interpret what they are seeing or trying to filter out distractions? Everyone seems to differ with regard to how easily they are distracted by outside influences.
Also, does a long saccade mean long saccade time or a long saccade distance? In other words, are all saccades of the same rate? Or is the cognitive load slowing these movements down?
Thanks!
This study compares apples to oranges. The labels are different for the different versions: Your Address, Your City, Company You Work For, Number of Colleagues versus Your Address, Your City, Company You Work For, No of Colleagues versus Name, Surname, Age, City. The label No is particularly problematic as the o in No is in superscript—that is, it looks more like a degree symbol. This abbreviation for number is culturally specific and not known everywhere. All of this completely invalidates any findings for me. Sorry.
I agree with Cliff Anderson on this. If you are seeking information about label alignments and saccade times—assuming longer saccade times imply more cognitive processing—you should have kept the labels identical.
With the short, one-word labels, the amount of cognitive processing is limited. The word can be understood in one glance; thus, the theory goes, leading to shorter saccade times.
With several words in one label, or with odd words such as No with the little o, the amount of cognitive processing is increased, regardless of the label positioning or alignment. So I think this probably limits the kinds of conclusions you can draw from your results. I guess you can tell I have done a bit of research since my last post.
I think the advice here to prefer right-aligned labels to the left-aligned ones—in the case of left-positioned ones—is not that straightforward. When dealing with longer forms, from a usability point of view, a user first needs to get an overview of a form’s structure—headings for subsections, form steps, etcetera—and content such as individual element labels. Getting a quick overview of a form that consists of ten right-aligned labels could be much harder than of a form that consists of left-aligned labels. So, I would be careful when shouting out such a rules like “always prefer right-aligned labels.” Rather, perhaps say “Prefer right-aligned labels for short forms; left-aligned labels for long forms.” And even then, what is short and what is long? I think there is no rule of thumb regarding this issue. But still, this is a good study, and it’s useful knowledge when designing highly usable forms!
Cliff, the information I provided at the very beginning of the article was that all the analysis was based on what Luke said in his article on form design. Please give it a read before continuing.
All the labels we tested were either very familiar to users—their own name, age, etcetera—or required some brain activity—the company a user works for, its number of employees, etcetera. We deliberately did not test just one single group of identical labels to broaden the validity of our results. Please see below my reply to Susan.
We aren’t comparing apples to oranges. Since you like metaphors, I’d say we are comparing Italian oranges to Spanish oranges to find the best of breed.
Again, all our users were Italian; and in Italy, n° is the correct abbreviation for number—equivalent to the English no.
Susan, we not only tracked the time users spent reading each label, but particularly, the time users needed to move from the label to the input field—back and forth, in some cases. We made our assumptions based on this travel time.
Sorry to both of you for my late reply, but some time has passed since the study—we did our tests back in March 2006—and it’s becoming more and more difficult to reply to comments.
Matteo, I hope you’re still accepting input on this immensely useful and much-needed research. Here’s another permutation that would be great to test—the opposite of bold labels over fields: Printed forms often use a lighter-colored and smaller font for field labels than are elsewhere seen on the form. Would using a smaller, gray—rather than black—font for labels over fields result in degraded scanning performance when (1) scanning for form content or (2) searching for data values in an infrequently used form? Phrased differently, could users selectively attune themselves to the less salient text and blind themselves temporarily to the more prominent visual content?
Excellent article, though I am late in finding it. Thankfully, it’s still relevant! One question I have is about accessibility. Does the label placement—whether horizontal or vertical in relation to its input field—impact at all how a user with a screen-reader would step through a form?
Jennifer, label placement is about interface—please read CSS2. :-) Accessibility is about structure.
That said, disabled users won’t be impacted at all by the placement you give to your labels.
Congratulations! It’s a very interesting study. I’ve noticed you didn’t test labels aligned on the left with fields just in front of the labels—not aligned on the form. Have you ever tested this option?
Wow! This article is nearly a year old, but its comments continue to grow. Thank you!
Now, about what Gil asked: I haven’t tested that option, but I sincerely think we don’t need an eyetracker to throw that design out of the window. With no alignment or whitespace to guide a user’s eyes, the user simply gets lost.
But you might find more on the subject on Luke’s blog, Functioning Form.
Fantastic study. In addition to these cases, I would have loved to see one where labels are embedded within the field.
The way it usually works is light grey labels replaced by darker color. Selecting the field would automatically select the whole label, ready for replacement.
Others have questioned the drop-down list conclusion and recommendation, so I won’t repeat their point. But my personal experience with a default value used for a label is a need to think twice about the use of the field. The mind senses that the label is out of place, and wonders if information will be lost if the value is changed. (It will, as noted by others.) The subsequent question is: What happens if the default value / label is left unchanged?
Wow! You research is incredibly valuable. I’ve always been in the left-aligned label camp, except for forms that are dedicated completely to entry, like Web site registration forms. As your research proves once again, logical deduction about cognitive load often leads to wrong design choices.
I’m curious what results you would get when the task is updating a single field on a form. How long does the subject scan the fields to find the one that needs an update? My guess now is that labels left-aligned above the field still would win out over left-aligned fields to the left of the field.
It’s curious that the HCI community has taken so long to learn about optimal label alignment. Look at almost all paper forms, and you see consistently the labels above the fields. Did paper form designers learn this lesson decades ago? (:>).
Did you guys also test the labels within the input field? This helps occupy less real-estate within the entire page, however, I wanted to know if there are usability issues with this treatment.
Somewhere along the line, I read that users report higher product confidence when its GUI elements are neatly aligned than when they are poorly aligned. I always assumed that right-aligned labels are perceived as poorly aligned. Is this an incorrect assumption?
Is there a trade-off between perceived credibility/confidence and cognitive load, or is there serendipitous synergy to be had?
Also, can these findings be extended to dialog boxes or only to short Web forms?
This is a very interesting entry, which I will apply to my work. However, I’d have preferred to see the forms with and without eyetracking data, for clarity. Also, I see that there are different forms and I wonder how this effects results.
Also, regarding “instead of using a separate label, make the default value for a drop-down list box the label.” This may be sort of a hard sell for people like me, who normally require others’ approval for publication. So good to have some supporting research. Yet none of the forms shown apply this, with or without the eyetracking data. But I’m willing to take your good word.
Thank you. That was very interesting. However, what I would like to know, since I am a beginner in page design and forms layout, is how should I code the form to display top position labels. And also how to place say two input text boxes next to each other on the same line, with some space in between another line with two input text boxes and so on, which is a typical design for travel agencies online or hotel reservations, which is what I am interested in designing. I have been searching the net for days, found a lot of examples, but nothing that can really help me yet.Your help would really be appreciated. Thank you.
My personal experience says that the left alignment is the most user friendly, mostly because new Internet people know this alignment from the bigger Web sites.
But I’m always ready to test new methods of creating forms!
Hi—Can anyone please tell me why exactly are the left-aligned labels to the right of their input so bad? I use bold ones, and I don’t think that it’s a bad idea at all. If a user needs to skim the labels, they are pretty well ordered, so there is no problem. They also don’t have the problem with too much whitespace between label and input. And if they are bold you can see them easily, but they don’t disturb you much. (I use just 1-to-2 pixel input borders.) And what’s more, you can provide some more explanatory information after the label, so there is no question where to put this.
More eye movements, yes, but the brain is better at grouping objects together with the help of spatial properties. Labels above the boxes makes it harder to interpret the text versus the box.
I wonder how these results differ from the rules for print-based forms? If you want a form to work equally well for print and Web, do you have to design two forms? I think the right-aligned labels would throw people in print forms because that is such a rare approach in print. But if you want the same users to feel comfortable switching between Web and print, you’d want a consistent look.
What are people’s opinions on placing hint text within text areas, where the hint text would act as a secondary label until the user inputs some value into the text area?
Great article, thanks. It has been very helpful to my form design challenge. For the redesign of an ERP application, I have been looking for the ideal label, field, and column placement for super fast scanning, optimal use of horizontal space, and clustering of fields by position. Eventually, I came up with an unconventional (maximum) 4-column layout, left-aligned bold labels above the fields, and a small bar indicating mandatory fields. Let me share
If a designer is looking for the solution mentioned here—that is, if he is having trouble in deciding on the alignment of fields—that obviously means there are lots of fields. From an enterprise application point of view, I would imagine multiple types of input fields with different sizes as well. In your test, you have just a single-line input field and a drop-down menu, whereas a designer struggling with this problem would typically have lots of fields of different sizes. I had a problem with long labels on a form with all sorts of controls—input fields of a single and multiple lines, radio buttons, and so forth. So when one has this kind of complex scenario, one may have to settle for a left-aligned layout as a compromise to counter the many other layout issues posed by this top-aligned layout.
So, in short, this is useful study, but to advise using this as a pattern, it needs to take a comprehensive look at the various scenarios I’ve mentioned.
Matteo, I hope you’re still accepting input on this immensely useful and much-needed research. Here’s another permutation that would be great to test—the opposite of bold labels over fields. Printed forms often use a lighter-colored and smaller font for field labels than are elsewhere seen on the form. Would using a smaller, gray—rather than black—font for labels over fields result in degraded scanning performance when (1) scanning for form content or (2) searching for data values in an infrequently used form? Phrased differently, could users selectively attune themselves to the less salient text and blind themselves temporarily to the more prominent visual content?
I’ve been redesigning a form for a disabled user with a screen reader. It’s very important to minimize whitespace between form elements and to vertically stack input fields. The view area is more wide than tall, so right-aligned labels are preferable to labels on top. But I can’t emphasize too much how important minimizing whitespace was.
Matteo’s article was interesting at the time, but that was 2006, and there has been a lot of research since then.
Let’s look at the specific recommendations:
“label position—Placing a label above an input field works better in most cases, because users aren�t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.” This recommendation assumed that speed of saccade and fixation, measured in this experiment, is the same as works better. True for very simple forms such as those illustrated here. Not true for more complex forms. Interpret this recommendation accordingly.
“alignment of labels—In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.” There was nothing in this experiment to justify the claim that left-aligned labels impose a heavy cognitive workload. In fact, if the labels are at all complex, left-aligned labels reduce the cognitive workload. Even if the labels are simple, there is no effect on thinking time—the effect is on saccade and fixation time, which is solely about eye-movement.
“bold labels—Reading bold labels is a little bit more difficult for users, so it�s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.” Agreed. I would love to see an experiment where this was tested.
“drop-down list boxes—Use them with care, because they�re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.” Agreed. Every form input device should be chosen with care, but not according to the importance of the data. Choose according to whether it is an appropriate or inappropriate method for that particular type of data.
label placement for drop-down list boxes—To ensure users are immediately aware of what you�re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.” Partly agreed. It is a good idea to offer an appropriate default if that default is an acceptable default to all users. Some defaults may appear patronizing or insulting in some circumstances—for example, pre-selecting a gender.
What about more recent research?
In 2008, Das, McEwan, and Douglas reported on their experiments at NordiCHI “Using eye-tracking to evaluate label alignment in online forms”. They tested simple forms, and found no advantage for labels above the boxes compared to right-aligned labels.
In 2010, Roland Feichtinger looked at labels under the boxes and also the distance between the labels and the boxes. He found that labels under the boxes can work okay, but the really important factor is whether the labels are clearly and unambigously associated with the correct boxes. Read about that in my article “Label Placement in Austrian Forms, with some Lessons for English Forms.”
What about other ideas about labels?
The web has moved on since 2006.
Forms often need to work across platforms—for example, mobile and desktop.
We also now understand that the Web is World Wide. You need to think about translating and localizing your forms.
Designers are experimenting with other ways of placing the labels—for example, inside the boxes
If your form has to work with small-screen mobile devices, putting the labels above the boxes may indeed be the best idea.
Not all languages read left to right, and other languages may occupy more—for example, German—or less—for example, Chinese—space compared to the same text in English. Putting your labels above the fields may make it easier to adjust to different languages.
Experimenting with strange label placement is rarely a good idea. See Jessica Kerr’s article “Fashionable Web Forms: Traps and Tips” on UXmatters.
The best designers now craft label placement just as carefully as everything else, varying the labels so that each placement is appropriate and harmonious. One block of fields might have labels above, because they are short and the fields are relatively long. Another block might have the labels to the left, right aligned. Sometimes the fields are embedded into the text—sometimes described as MadLibs’ style forms.
What is today’s best advice?
If your form is simple, needs to work on mobile devices, or will be translated, think about putting the labels above the fields.
If your form is more complex, think about putting the labels where they will be easy to read. This usually means left aligned.
Avoid getting creative with your labels. Save your energies for other areas of your designs or Web sites. Make forms very, very simple and obvious to use.
Above all, test your designs with your target users. They are likely to surprise you.
Impressive! Recently, we did a study with some students, having a setup comparable to yours. Letting them look at different registration forms. All in all, we can confirm your findings. The reason i—as another professor in perception science and psychology has said#8212;because people are used to scanning screens from top to bottom, resulting in a lower effort to understand what is shown to them.
Hi—I’m new to developing. I’m trying to integrate a log-in form into my Web site. It is working fine. But the problem is that, when I have to enter the name or the email address into the form, the suggestions that the form provides for names and emails already entered don’t have the proper alignment. I have been trying to fix this issue, but I’m not able to figure it out. Please help.
I have some clarification on “Left-Aligned Labels Above Input Fields.”
If my form has around 30 to 40 labels on one page, is this approach suggested or not? Because if I follow this approach, vertical scrolling will come. (For our requirement, vertical scroll should not come. Our’s is 1024 X 768 px layout.)
I am too late in finding it—realized that after seeing the dates of posted comments. I still find it quite relevant as I have come across this situation many times when I needed to decide the best way for label placement in a form design.
In my opinion and as per the article, we can prefer the left-sided, right-aligned labels as the most appropriate option.
However, I would like to have your inputs on designing for a multi-column form. If we have a form with three columns of label-field pairs, the left-positioned, right-aligned label placement reduces the readability, as Luke Wroblewski suggests.
In that case, how can we use the visual elements to retain the readability, still using the best label placement method.
uxfindings.blogspot.com: One might also conclude that, if the listbox is so catching, it would be best to have such a box at the top of the list. If it falls further down the list, the user’s eyes are likely to be drawn down the list. If that happens, they must first look back up to the top. Great article. Thank you for providing this.
Most people in the western world read left to right, not top to bottom. In my opinion, as long as the labels and fields are properly aligned then left to right is still better. The issue with top to bottom is that if the screen is crowded the label could get confused with the input box above it but single column makes both easier. However, top to bottom makes more sense for smaller input devices (like a smartphone) and left to right makes more sense for computer screens where a mouse can be used.
At Consultechnology, an ITC company with offices in Milan and Lamezia Terme, Italy, Matteo conducted research projects that focused on natural interactions between people and computers, automotive applications, and universal design—specifically for the elderly and the disabled. Matteo began his career in information technology working for Anixter International at their Milan and London offices, managing their intranet design and programming team. Then he worked as a project manager for a leading Italian Web agency in Milan, where he managed Internet projects for international Fortune 500 companies. Matteo is a sought after speaker at national and international seminars—including CHI2005, Macromedia, and VNU to mention just a few—and is a professor for the Interaction Design course in the Masters program in Humanistic Computer Studies at Bicocca University, Milan. He has written numerous articles on the subjects of natural interfaces, user experience, and technological innovation. He is also the UXnet Local Ambassador for Milan. Read More
