Labels placed inside the form field (aka “inline labels”) are widespread in mobile apps and sites – almost to the point of being a best (mal)practice. Yet in every usability test we’ve conducted inline labels have suffered from major usability problems. Mobile included.
Perhaps the popularity of inline labels on mobile is due to Apple’s extensive use of them, or the great simplistic look they afford, or their space efficiency – most likely it’s combination of all those factors. And while good looks and space efficiency are valid benefits of inline labels, these are by far outweighed by the major usability drawbacks of inline labels, the most significant of which is the loss of context.
At their core, form fields are all alike. They are rectangular boxes on the screen. What distinguishes one field from the next is its label – the label is the defining context for that box. The problem then arise when the label disappears (as they do with inline labels when users begin typing, and in some cases even upon entering the field) – suddenly the only context for the field is the user’s own input. This not only makes it more difficult for users to fill out the fields, it also makes it much more difficult to correct any validation errors they run into.
During the m-commerce research study we observed numerous test subjects struggle with fields that had inline labels. This echoed what we observed during our e-commerce checkout research where subjects also struggled with inline labels – only the problem proved even more severe on mobile. During the m-commerce study, inline labels caused severe flow and typing issues and on validation errors the subjects often deleted their entire input just to see the label again. In a few instances these issues were so severe the subjects abandoned the site.
Inline labels are a prime example of false simplicity. They look simple, but are in fact very tricky to use. This is especially true when it comes to fixing validation errors; Fandango offers up a good example.
During the study, we observed multiple test subjects enter “Houston” as their search query at Fandango, however, this returned a cryptic validation error: “Please enter a valid location.” Why on earth would Houston be an invalid location? Well, it turns out the inline label says “City, State OR Zip Code”, so users will have to write “Houston, Texas”. However, because the inline label isn’t visible anymore, the user has no way of knowing this. Of course a better error message would have helped too, but being unable to see vital context for the field forces the user to either guess or delete their entire input just to see the label again. Which of course were the two courses of action the subjects resorted to – quite understandably to great vexation.
It is this loss of context which makes inline labels a poor choice in most cases. However, there are a few instances where inline labels do have merit.
When there’s only 1-2 fields (for example a search field or perhaps a sign-in form) the user will rarely forget the context as the entry type is singular and frequently executed. However, as soon as there are more fields, different types of data is needed, or the fields are used infrequently, inline labels become problematic. Also, if there are requirements for the field input, inline labels are typically a poor choice even if it is only a single field, as the earlier Fandango “Houston” example illustrates.
It should be underscored that inline placeholder text in and of itself isn’t bad (in fact, it’s a great feature), it just shouldn’t be used for the primary label. Instead, inline placeholder text is perfect for brief descriptions that may help frame or further clarify the field’s context without being necessary to understand it.
Formatting examples is a good case, where even though you should accept all formats, it is still a good idea to provide an input example (because the user can’t know that you accept all formats and want to use a safe format to begin with; that is, a formatting example informs the user of what they can safely use). So for a phone field in a sign up form, you’d want “Phone number” written as an independent (permanently visible) label and then have “e.g. 315 415 7777” as inline placeholder text.
The Exception to the Exception
Inline labels shouldn’t be used for drop-downs either. A great deal of sites with list sorting features have the label “Sort by” as a drop-down option (in effect an “inline label”) as opposed to a separate permanent label. Despite the sorting drop-down being a single field, this particular type of inline label caused problems during testing.
When subjects tested 1-800-Flower’s mobile site, some thought the drop-down label “(sort by price)” meant that the list was already sorted by price – even though it clearly wasn’t. It was only after opening the drop-down field that the subjects realized that “(sort by price)” was the label for the field and not the current sorting.
Users can’t be expected to minutely study labels in order to figure out their meaning – rather the text is hastily scanned to form a quick understand of the interface. As a consequence, when embedding the label as an option in drop-downs, it is easily interpreted for the current / selected sorting, and this type of inline label should therefore be avoided despite the sorting drop-down being a single field.
In summary, the general advice is to avoid inline labels in forms. The exceptions are single standalone fields or “singular-purpose-two-field-frequently-used forms”, where inline labels may be used if space efficiency and aesthetics are significant concerns.
In the case of drop-down fields or regular text fields where there are input requirements (that may yield validation errors upon submission), the field should always have a separate permanently visible label regardless of the number of fields. In longer forms of three or more fields, separate labels should always be used too, to ensure the user has the necessary context at hand when filling out the form.
When separate labels are used, the inline placeholder text may be used for formatting examples or other brief descriptions that can help guide the user without being necessary to understand the field.