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 a 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 arises when the label disappears (as inline labels do 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 users struggle with fields that had inline labels. This echoed what we observed during our e-commerce checkout research where users 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 users often deleted their entire input just to see the label again. In a few instances these issues were so severe the users 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.
For example, during the study, we observed multiple users 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 users 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 are 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.
For example, a phone field in a sign up form should have “Phone number” written as an independent (permanently visible) label and then have, for example, “315 415 7777” as inline placeholder text.
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.
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 (mis)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.
A final note: some sites are experimenting with “Floating Labels” and similar concepts, where the label sits inside the field but then floats to the top of the field when the user begins typing.
This solves the context issues of inline labels and the pattern thus shows promise. It is, however, worth noting that there’s currently no in-depth usability testing available on the performance or potential side effects of this design implementation.
If experimenting with floating labels or similar designs, it is recommended to pay special attention to the form validation error experience, since many of the “early adopter” sites with Floating Labels haven’t implemented the validation error state very well. Typically, these sites only allow room for very short or no error messages, which is highly problematic. Therefore, make absolutely sure you take great care in implementing the error message state if deciding to pursue a floating label design.
This article presents the research findings from just 1 of the 850+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” mobile e-commerce user experience.
Join 22,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
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.
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).
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!
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!
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
+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
© 2021 Baymard Institute US: +1 (415) 315-9567 EU: +45 3696 9567 email@example.com