Fashionable Web Forms: Traps and Tips

By Jessica Kerr

Published: November 1, 2010

“We can use what we know about human perception to help people move through forms quickly, easily, and successfully.”

I know as well as anyone that we humans are very visual creatures. My area of specialty is the design of forms and, as you can imagine, a significant part of my work focuses on visual design and layout. Recently, I published a series of six articles about human perception, or how people see, and the impact this has on the way we should design Web forms. We can use what we know about human perception to help people move through forms quickly, easily, and successfully. Form design is not about aesthetics just for aesthetics’ sake.

Don’t get me wrong. I do think the attractiveness of a user interface is important. My concern is that people sometimes pay disproportionate attention to how sexy, pretty, or aesthetically pleasing a form is, in comparison to how well a person can actually use it. If users can’t successfully fill out and submit a form, it’s a waste of pixels—not to mention everybody’s time.

As a result of this fixation on fashionable forms, it seems, every other week, there is a new article with a title like “20 Fetching Forms” or “How to Jazz Up Your Forms with CSS and JavaScript.” I get excited by the possibility that these articles might show us some way to help people fill out forms faster or make fewer errors. Alas, they frequently do exactly the opposite—promoting techniques that are often unnecessary reinventions of the metaphorical wheel or, worse still, result in forms that are harder for people to fill out.

So let’s put some novel form-design approaches under the microscope and see how they fare. In this article, I’m going to examine the following Web form fashions:

  • unconventional label placement
  • creative required-field indicators
  • sliders
  • hidden contextual Help

Unconventional Label Placement

“A field label tells people what sort of information needs to go into a text box or other form widget. This means they need to read the label before they get to the field.”

A field label tells people what sort of information needs to go into a text box or other form widget. This means they need to read the label before they get to the field.

For Web forms in languages that are read from top to bottom and left to right, designers usually place field labels above or to the immediate left of fields, leveraging this principle of reading order. However, I have seen a couple of Web forms that had the labels below their fields, as shown in Figure 1.

Figure 1—A Web form with labels beneath the fields

Web form with labels beneath the fields

Assuming a form is in a language that people read from the top of a page down, positioning a label beneath a text box results in people’s receiving form elements in the reverse order from what they need—that is, text box, then label rather than label, then text box. Because users first see a field, then must look underneath it for its label, then look back up to fill out the field, their experience of filling out the form would be to take two steps forward, then one step backward; jump forward three steps to the next label, take one step backward; jump down to the next label, and so on.

This continuous forward and backward movement is likely to get very tiresome, very quickly. Obviously, it is much more work for users than if labels were always above or to the left of text boxes.

Another modification of the traditional placement of labels that is starting to garner interest around the Web is inserting them inside the text boxes, as shown in Figure 2.

Figure 2—A Web form with labels inside fields

Web form with labels inside fields

There are many reasons why this is a bad idea:

  • Once a user starts typing in a field, its label disappears. So the only way users can check what they are supposed to be doing—if they are interrupted, for instance—is to remove their answers and hope the labels reappear.
  • If a label doesn’t disappear as soon as a user selects an insertion point in a field, either the label accidentally gets submitted along with the intended text or the user must delete the label manually.
  • Fields with text in them appear to be complete, so you’re likely to end up with much higher error rates.
  • Once a form is complete, there is no way for users to review what they’ve typed and confirm that they’ve provided the right information.
  • There is no way to keep a usable visual record of the information a user has typed, because a printed or saved form a user has filled out has no labels.
  • This approach is feasible only if a field label is very short. So once you get beyond a really simple sign-up form or the like, it means inconsistent formatting between questions on your form.
  • This technique relies on JavaScript and is hard to implement accessibly.
“There are only a very few instances where space is at such a premium that there is no room for labels outside text boxes….”

I could go on, but Caroline Jarrett has already written on this topic in depth in her UXmatters column “Don’t Put Hints Inside Text Boxes in Web Forms.” I strongly suggest your reading that piece for some great background and empirical evidence that putting labels inside fields is really not a good idea.

So why do it? Some people argue that it makes the form neater. I think this subjective claim is debatable. It’s also a bit like getting rid of the food in your fridge so it’s cleaner. While the slightly obsessive neat-freak in me appreciates this desire, we need to resist such impulses if we’re going to create good user experiences.

Another argument for putting labels inside fields is that doing this saves space. This is certainly true, but there are only a very few instances where space is at such a premium that there is no room for labels outside text boxes—for example, if you’re squeezing a couple of sign-in fields into a small site header. But you need to be very careful with the implementation of this approach—so labels disappear on a user’s selecting an insertion point in a text box, for instance—to maintain usability.

Last, but not least, the most unconventional label placement I’ve seen uses animation. A label is initially inside a field, then, as a user starts typing data, slides out to the left of the field, as in the CSSKarma sliding form labels demo. While this approach is certainly novel, I can’t see any benefit to it. It doesn’t save space, because you need to reserve space for the labels once they slide out of the text boxes. The animation is distracting, and you are still left with many of the problems I mentioned earlier, like users mistakenly thinking they’ve already filled the fields out.

Creative Required-Field Indicators

“The red asterisk works well because it has ‘double visual emphasis.’ Both the color and the shape are visual cues, so this indicator is accessible to people with color-deficient vision.”

If you ’re going to use some sort of indicator on your form to point out which questions users must answer, why not stick with the de facto standard—a red asterisk (*)? This may not be the best indicator we could ever have designed, but through its use across a large number of Web sites, it has become a well-known convention. And as Luke Wroblewski says, the red asterisk works well because it has “double visual emphasis.” Both the color and the shape are visual cues, so this indicator is accessible to people with color-deficient vision.

While there are still some people who don’t yet know what this indicator means, there are definitely more people who don’t understand what a red bullet (Figure 3) or a yellow bar (Figure 4) means.

Figure 3—Red bullet as a required-field indicator

Red bullet as a required-field indicator

Figure 4—Yellow bar as a required-field indicator

Yellow bar as a required-field indicator

While there is an explanation of what a yellow bar means at the top of the form shown in Figure 4, experience and research show that most users don’t read instructions. Thus, there is a good chance they’ll miss this explanation. Better to just use the convention and know that most users will have no trouble understanding it.

What’s the most troublesome alternative required-field indicator I’ve encountered? Figure 5 shows an example in which the labels of required fields are underlined. Not only is this an unfamiliar approach, we all know underlined text has another well-established meaning on the Web: indicating a hyperlink. This is definitely not a good choice for indicating required fields.

Figure 5—Underlining as a required-field indicator

Underlining as a required-field indicator

Sliders

“Most sliders on the Web don’t offer such graduated settings. Instead they just provide an alternative way of choosing from among a limited set of predefined options.”

The standard set of form controls—text boxes, radio buttons, check boxes, and drop-down list boxes—has served us well for many years. However, recently a new form widget has surged in popularity: the slider. I say new even though, in the physical world, slider controls have been around for many decades, on everything from air conditioning units to graphic equalizers.

In the physical world, sliders are similar to knobs: they enable selection along a continuous range. For something fine grained, like adjusting the amount of treble or bass on a sound system, this is an appropriate control. But most sliders on the Web don’t offer such graduated settings. Instead they just provide an alternative way of choosing from among a limited set of predefined options.

Figure 6 shows an example of just such a case. A user must choose one of eight different amounts. Giving these options in a list box would make this user interface more usable and accessible.

Figure 6—A slider with only eight discrete options where a list box would be preferable

Slider with only eight discrete options

When users must choose among a relatively small set of predefined options, the use of a list box is preferable for the following reasons:

  • The control itself communicates to users that they can select just one option from a predefined set, whereas a slider suggests a continuum of options.
  • Users can manipulate list boxes using either the keyboard or the mouse, whereas sliders usually require mouse manipulation.
  • Users are more familiar with list boxes and know how to operate them.
  • List boxes are highly accessible.

Interestingly, Australia’s number one job site SEEK tested the use of a slider in place of a pair of list boxes. The SEEK home page primarily facilitates users’ searching for a job, including setting their desired salary range, as shown in Figure 7.

Figure 7—SEEK home page at the time of the test

SEEK home page

In a typical A/B test, SEEK presented this page to 24,000 visitors with either a salary slider, shown in Figure 8, or salary-range list boxes, as shown in Figure 9.

Figure 8—Salary-range selection with a slider on SEEK

Salary-range selection with a slider on SEEK

Figure 9—Salary-range selection using two list boxes on SEEK

Salary-range selection using two list boxes on SEEK

SEEK found that the conversion rate for users of the slider was 8% lower than for users of the list boxes. That is, fewer users included salary range as a criterion of their search when the mechanism for doing so was a slider when compared to a pair of list boxes.

Anecdotal evidence suggests this may be because the slider is a relatively new and unfamiliar form control. When visitors come to the SEEK home page, more often than not, they are looking to quickly get to a list of jobs that meet their criteria. They may see a novel widget like a slider as a barrier to achieving this goal. Consequently, SEEK has decided to use the pair of list boxes rather than the slider for salary-range selection on their home page.

It is worth noting, however, that SEEK has decided to use a slider on the panel that lets users refine their search results, as shown in Figure 10. Here the thinking was that the unconventional control might help draw attention to the relatively new refinement capability.

Figure 10—SEEK salary slider on the Refine your results panel

SEEK salary slider on the Refine your results panel

Sites often use sliders to offer users a fine-grained continuum of options when a small set of predefined options would suit their needs perfectly well. For example, the slider shown in Figure 11 moves in $10 increments, enabling users to select a maximum cost per night somewhere between $0 and $1,000 when searching for accommodations. But do users really need to be able to differentiate between $740 per night and $750 per night? Surely a few values would be sufficient, in which case a series of check boxes showing these would be a better solution. (For the reasons why check boxes rather than list boxes would be best, see Greg Nudelman’s column “Numeric Filters.”)

Figure 11—A slider presenting more detail than is necessary

Slider presenting more detail than is necessary

Sliders aren’t all bad, though. In some cases, they can really enhance a user experience. For example, the slider shown in Figure 12 lets users indicate the value of their car for insurance purposes. A user can leave the slider where it is when the page loads; this is the market value. Alternatively, a user can adjust the slider within some predefined range, indicating what they consider their car’s replacement value to be. As soon as the slider stops at a value, the premium adjusts accordingly.

Figure 12—A slider gives users options for how they want to interact

Slider gives users options for how they want to interact

The slider in Figure 12 works nicely for a number of reasons, as follows:

  • In this case, it is important to communicate the end points of the range from which a user can choose a value, so the visual representation of a slider is highly appropriate.
  • There is a continuum of fine-grained options a user can select.
  • The slider lets a user easily and immediately see the impact of selecting different values on the premium.
  • If users know the exact value for which they want to insure their car, they can type it into the text box at the middle of the slider control.
  • The slider introduces a somewhat interesting interaction at the end of a fairly boring form—boring by necessity. This is insurance after all.

Hidden Contextual Help

“Contextual Help provides just-in-time, supplementary information within a form.”

Contextual Help provides just-in-time, supplementary information within a form. An example would be a tip about acceptable password formats beneath a Password text box.

You don’t have to look far on the Web to find forms that hide contextual Help behind some sort of icon, like a question mark, as in Figure 13. Like red asterisks for mandatory fields, this has almost become a de facto standard.

Figure 13—Question mark Help icon

Question mark Help icon

But if contextual Help exists to help users fill out a form correctly and with confidence, why hide it? Presenting Help directly on a form page means it is there for users, whenever they need it, without clicking or hovering. Plus, you can style Help so it has less visual prominence than other form elements. The testing I’ve done with users suggest they do not get distracted by such Help, but find it when they look for it. Figure 14 shows an example of such contextual Help.

Figure 14—Contextual Help that is always visible

Contextual Help that is always visible

Hiding contextual Help behind an icon means users are much more likely to miss it—especially, but not only, users who are using a keyboard or assistive technologies. Not seeing or having access to Help increases the occurrence of validation errors and results in greater user dissatisfaction.

“Hiding contextual Help behind an icon means users are much more likely to miss it—
especially, but not only, users who are using a keyboard or assistive technologies.”

Using icons to provide a pathway to contextual Help also means users must stop what they are doing and click a Help icon to even see what the content behind it is about. The need to take this separate, flow-breaking step may result in disappointment if the Help content doesn’t meet their expectations or needs.

However, if you must use an icon to indicate the availability of contextual Help, it is best to stick with the established convention of a question mark. Styling your Help icon to match your branding or theme might be cute, as in Figure 15, but it doesn’t provide much information scent.

Figure 15—A Help icon that is cute, but unusable

Help icon that is cute, but unusable

Another approach to the presentation of contextual Help is having it appear only when users select an insertion point in a field, as shown in Figure 16. The animation this approach uses is good for drawing the attention of sighted users’ to Help they might otherwise have missed, because humans are very sensitive to movement within our visual field.

“Another approach to the presentation of contextual Help is having it appear only when users select an insertion point in a field.”

However, this kind of animation could well become annoying on a long form. But whatever a form’s length, there are some other disadvantages to this Help display technique that are also worth considering:

  • Users don’t know Help even exists until they navigate to a field, by which time they may have already gone through the process of formulating their answer and, thus, may need to do some mental rework.
  • When a field is something other than a text box—like radio buttons—users may not get the Help they need until after answering.
  • You need to be very careful about where the Help appears to avoid covering up the related field, the following question, or other key components of the screen.
  • The Help may not be accessible to assistive technologies.

Figure 16—Help that appears only when users are typing a value in a field

Help that appears only when users are typing a value in a field

One reason you might want to hide contextual Help is if only a small minority of users would need it. Everyone would need the password tip I mentioned earlier, but clarification about why a form is asking a certain question might be of interest to only a small number of users—for example, those who are particularly concerned about data privacy.

In such cases, I’ve found that it is good to give users at least a clue to what the Help is about. You can do this by highlighting the parts of a label or question to which the help relates. Figure 17 shows an example of this, where a dashed underline and blue font indicate the availability of Help on hover.

Figure 17—Hinting at the availability of contextual Help on hover

Hinting at the availability of contextual Help on hover

In Summary

“We usually place labels above or to the left of text boxes because that placement facilitates the fastest, easiest interaction with a form for users.”

If a certain form-design technique is well established, there’s a good chance it has been thoroughly tried and tested. For instance, we usually place labels above or to the left of text boxes because that placement facilitates the fastest, easiest interaction with a form for users. And trust me, users much prefer to get form filling done quickly and effortlessly rather than to have a painful experience using a form that’s pretty.

Use this knowledge to your advantage. The key to designing highly usable forms is to make sure whatever widgets or methods we adopt, old or new, they are fit for their purpose. As for any task, choosing the right tools for the job—in this case, form filling—makes the job much easier.

So, if you’re thinking about a novel approach to form design, make sure you keep the overarching goal of the form in mind: collecting error-free data, while placing as little burden on users as possible. If you align your choice of form widgets with this goal, you’ll design successful Web forms.

9 Comments

I find it hard to agree with the labels underneath. You mention the reading order, but there is no reading of a text box, I believe it is quickly chunked along with the label without any stress.

Caroline Jarrett has posted a study on this, showing how intuitive these types can be, depending on the distance between the two.

@Offir

Thank you for taking the time to comment.

There may be no reading order for an individual text box, but there definitely is a reading order for a form as a whole. If you’re going from top to bottom and reading a left-to-right language, you will encounter text boxes either before or after their respective labels.

The study Caroline wrote about is indeed very interesting, and I’ll happily admit being a little confounded by its results. This is the first and only time I’ve seen empirical data on the performance of labels positioned underneath fields. I’d be very curious to see if anyone can replicate those findings and will happily change my recommendation if need be!

Another thing to keep in mind is that there may be a different result for labels of one or two words—as shown in the aforementioned study—versus sentence-style questions.

As you and Caroline rightly point out, proximity of the label to the field is more important than its relative location. In the study that Caroline refers to, the labels are positioned close to their fields, and indeed, results were poorer when they weren’t. This suggests that both elements are being seen in a single saccade.

In the example I give in Figure 1, however, the labels are not only below, but to the right. This would require greater eye movement and I believe would give worse results than labels positioned above and to flush left.

Best regards, Jessica

Very insightfull article. Well explained. What would you advise for the order of fields like address and name? Next to each other or in one line beneath each other? Thanks Jessica!

@Annemarieboon

Thank you for your feedback on the article.

My overarching advice for the order of fields like address and name is to reflect real-world use as much as possible. In my culture, for example, it is conventional to say the given name before the family name—for example, Jessica Kerr, where Jessica is my given name and Kerr is my family name. Thus, the given name field should ideally be placed prior to the family name field.

In other cultures, this order can be more complex, or reversed, so you should adapt a form’s design accordingly. (For more information about naming conventions, see my article “The Name Riddle” on the Formulate Web site.)

Whether you put the fields next to each other or one underneath the other depends on the overall layout of your form. By default, I usually recommend aligning fields one underneath the other, so users can move quickly and seamlessly down a page or screen in a single vertical flow. If this is how your form is laid out, putting a name or address field off to the side means users are more likely to miss it, because it is out of their field of focus.

On the other hand, a form might have a number of fields that are beside each other; in which case, there is less chance of users not seeing a field. It’s really all about making it clear to users, at every step, which field comes next. (For more on this, you might be interested in my article on alignment, as well as the series I did on visual perception and the design of forms.)

In a form from Skitch—which they’ve since redesigned—there is a tension between the vertical clustering of some fields and the intended horizontal movement. It’s a good illustration of the pitfalls of two-column forms, and indeed, the redesigned version of the form has only one column.

Hope this helps, Jessica

Wonderful stuff! I’ve found many of the same things in my testing, too.

“Hiding contextual Help behind an icon means users are much more likely to miss it—especially, but not only, users who are using a keyboard or assistive technologies. Not seeing or having access to Help increases the occurrence of validation errors and results in greater user dissatisfaction.”

I’ve actually had a lot of luck with descriptive links instead of question mark icons. In other words, make the Help link something the user is already thinking of: Why do we ask this? How do I format this? What do I enter? What will you do with this information? They don’t even know they’re clicking Help.

@cliff anderson

Thanks for your feedback, Cliff.

I agree that descriptive links can be just fantastic. They have strong information scent, match a user’s mental model, and help a user interface seem personable and responsive.

About labels inside fields: “There is no way to keep a usable visual record of the information a user has typed, because a printed or saved form a user has filled out has no labels.”

This is wrong, you could set a print stylesheet where labels are outside of the fields.

@Nek

You’re right, you could set a print stylesheet where the labels are outside of the fields. But I suspect many (most?) users would assume that printing a Web form would get them a hard copy of exactly what they see on the screen, so not even bother. After all, it’s only us technical folk who know about print stylesheets.

Also, it’s obviously more work to have to set up a print stylesheet to get around the labels being inside the fields. Given all the other disadvantages of this approach, I would have thought adding extra work was the nail in the coffin. Unless there’s some significant advantage that I’ve neglected?

Cheers, Jessica

Thank you for an insightful article.

There are a few bits I don’t quite agree with—forms with labels inside fields—but you’ve prompted me to think through my decisions and weigh them carefully against the concerns you raise.

Thanks again.

Join the Discussion

Asterisks (*) indicate required information.