Article overview

Mobile Form Usability: Never Use Inline Labels

· By · 19 comments ·

An example of inline labels that disappear as soon as the field is activated, making it very difficult for the user to fill out the form.

This is the 7th in a series of 8 articles on mobile usability that draw on findings from our mobile e-commerce usability report.

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.

The Problem

Example of fields with and without labels. Ultimately the label is the only thing that makes one field unique from the next.

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 mobile e-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 mobile e-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.

Exceptions

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.

Conclusion

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.

Ethan Danstrom June 4, 2013 Reply to this comment

Very nice article, thanks. I wonder if 1-800-FLOWERS changed the label to

(sort by price?)

if that might have cleared things up and still saved them the space they needed. Inline or not, the label itself needs to be well thought you. I can’t believe that the inline example used by Fandango was invalid. It reminds of a big brother doing the “Stop hitting yourself, stop hitting yourself” act. Ugh.

Jamie, Baymard Institute June 4, 2013 Reply to this comment

Hi Ethan, thanks for commenting.

You’re right that copywriting is a major aspect of this particular instance. However, on other sites with less ambiguous inline labels for their sorting drop-downs, there were still problems – especially when a value was selected. In these cases, the drop-down suddenly just says “High to low”, which makes little sense to the user unless they actually open the drop-down and then see that it is “[Sort by price?] High to low”. This problem can of course be alleviated with clever copywriting too, by simply prefixing the selected value with the sorting column, so “Sorted by [column]: [direction]”, that is: “Sorted by price: high to low”. However, this reads really strange when the user then opens the drop-down to select another value, where the values suddenly read:

(Sort by price?)
High to low
Sorted by price: Low to high

Of course all the options can then be prefixed, but that seems rather redundant not to mention difficult to scan, and it will be confusing as there should be a distinction between “Sort by” and “Sorted by”:

(Sort by price?)
Sort by price: High to low
Sorted by price: Low to high

The problem with inline labels in drop-downs is that they must work both as a label and as a value / option to be selected among a set of options. By having “Sort by:” as a separate (permanent) label, the problem is resolved.

Of course copywriting / microcopy is paramount in both cases, and particularly if you do decide to do inline labels. And I think you’re right that including the question mark in 1-800-Flowers’ case would have helped (but the field would still suffer from the label / value issue described previously in this comment).

Graeme Blackwood June 5, 2013 Reply to this comment

The growth in use of inline labels is I think through designers rightly attempting to reduce the sense of clutter of large forms to make them more enjoyable to use. But the evidence here about most methods is pretty unequivocal.

For the same reasons above, I don’t tend to use placeholder text for my help text, I add it underneath the field. As you can imagine, having labels above and help text underneath every field on a large form make it even more cluttered and daunting.

One of the wonderful things about the web is that we can respond to context. I deal with the help text for each field by hiding it initially; only showing it when the field is in focus and the user is ready to see it.

I wonder if initially inlining labels, then moving them above the field when the user focuses on it or starts typing would achieve the best of both worlds.

Also multi-step forms can be good at reducing clutter, though I quickly get irritated if there are more than about three steps and no indication of how far I have left to go!

Jamie, Baymard Institute June 5, 2013 Reply to this comment

Thanks for your input Graeme!

I like your idea of initially hiding the help text (to keep the form’s appearance simple) and then showing it upon focus below the field. We’ll have to test this implementation in a future study.

One thing I personally find with placeholder text examples – although I must underscore this is my personal experience and not something we have researched (yet!) – is that I find the form less daunting because the fields look filled out already. Of course I know they are not, but because there’s already something in the fields, it still feels less daunting than when faced with 10 empty fields to fill out. Would love to do some user testing on this too, and see how placeholder text affects the user’s perception of forms in general.

Anyway, I’m going off a tangent here.. thanks for your comment, always appreciated!

Wen June 25, 2013 Reply to this comment

It would be interesting if you guys could test out Square’s implementation. https://squareup.com/
They leave inline labels in the field even after the field is in focus. They only disappear after the user starts typing.

Christian, Baymard Institute June 27, 2013 Reply to this comment

Hi Wen,

We tested sites with this approach as well and they suffer from the same severe issue: as the user starts typing all context is lost. Sorry if this was unclear in the article, I can see how the intro image can be a bit misleading.

Again, the general advice is to avoid inline labels. (exceptions are single standalone fields or “singular-purpose-two-field-frequently-used forms”, which both Square and Dropbox sign-in fields qualify as)

Wen June 25, 2013 Reply to this comment

The new Dropbox site also uses this pattern. In dropbox’s case they even change the text color of the labels to a lighter gray after the user focuses on the field.

Stomme poes October 1, 2013 Reply to this comment

This is a browser implementation, rather than a site implementation. If you use the HTML5 placeholder attribute, most browsers leave that text in place while the input is focussed, removing it only when there are visible characters typed in by the user.

Caroline Jarrett July 9, 2013 Reply to this comment

Thank you for this useful article. Your observations entirely chime with mine, and I’m also very much against the use of labels inside text boxes e.g.
http://www.uxmatters.com/mt/archives/2013/02/dont-put-labels-inside-text-boxes-unless-youre-luke-w.php

Tim Allen October 4, 2013 Reply to this comment

Excellent post, Jamie! You are absolutely right to highlight this seemingly growing trend towards inline labels – I wonder whether the implementers ever get frustrated when using their own forms?

Something I find even more frustrating is when the input field is pre-filled with an example which doesn’t automatically clear when the user clicks on the field. This can result in the user’s entry becoming inserted within the example, and the only recourse is to select the entire entry, delete it and start again.

Sean October 31, 2013 Reply to this comment

The user should be looking at the field before they enter it to input something. Especially if there is no regular label that effectively tells them what is valid input.

Most forms I’ve seen, when there is a regular label they don’t make that label descriptive either. So for the example of the location that needed to be entered, the label for such a field in my experiences has simply been something like “Enter a location”. That is even less helpful than a disappearing inline label that actually tells the user what is considered valid.

Christian, Baymard Institute November 11, 2013 Reply to this comment

Hi Sean,

We are not saying you cannot use inline formatting examples (an inline placeholder text with a valid input example), this article just concerns the form field labels.

In fact a placeholder formatting example can be a decent combination with permanently visible labels.

Larry Piper November 5, 2013 Reply to this comment

Congratulations, you solved a problem you invented! The “major problems” with inline labels you identified are bad design/UX practices, not an inherent problem with labels like you try to suggest.

If you can’t remember what you are typing after the label disappears in a form box, you’ve got bigger problems in your life than filling out forms.

Christian, Baymard Institute November 11, 2013 Reply to this comment

Don’t quite follow the logic here. If end-users are consistently observed to experience severe form filling issues when trying to interact with forms using inline labels, then that’s a real UX problem to solve for designers & developers.

Ian Hamilton December 5, 2013 Reply to this comment

Pretty shocking lack of empathy there Larry. Even for purely seflish reasons, when you hit 60 years old you’ll have a 50% chance of being disabled. There’s a decent chance that will include some degree of cognitive impairment. If you’re in that situation, do you want to be excluded from using forms online?

That’s the real big issue, but it still affects everyone. I’ve seen in testing just within the last couple of weeks inline labels not only excluding people with pretty minor cognitive impairments (or minor vision impairments, thanks to the low contrast of the labels), but also causing problems for customers without impairments, because, to be frank, forms are a laborious chore, so people rush through as quickly as possible without reading anything. In that context, making helpful information even harder to spot is just pure lunacy.

Olga January 14, 2014 Reply to this comment

Check this micro-interaction providing an elegant solution about labels inside the fields, you will love it!
https://vine.co/v/htbYvziYi0p

Iain Collins April 16, 2014 Reply to this comment

With regard to the location field, I don’t actually think the lack of label is the problem – especially as just “Location” would be the best label to use (as it’s short and most quickly readable) and “City, State or Zip” would be appropriate for placeholder text.

I think the problem there is the UX itself – if an exact match with ~100% confidence is not found it should simply prompt with a list, with the most likely options at the top. To help steer user behaviour in future selecting an option could then prefil the input with the selected option and trigger a resubmit.

I imagine in most cases there will only be 2 or 3 likely values at most. If there are more options (e.g. town names like “Fairview”) you could prompt to select a State from a list (and for connivence default to pre selecting the same state in future for that user, if the list of states is displayed in subsequent lookups).

Phoenix September 10, 2014 Reply to this comment

Read up on “floating labels”. You may want to update your post after you do. It’s a good balance between the space saving that happens from just placeholders inside text labels, and the ability to remind a user what she’s typing at the moment.

Joao Cunha December 22, 2014 Reply to this comment

+1 for extending this research to float labels.

It all started here (ish): http://bradfrost.com/blog/post/float-label-pattern/
And this is my version of it: https://medium.com/@joaocunha/enhancing-the-ux-of-dubizzles-new-place-an-ad-process-365370efb788

Post a comment!

Close overlay