During both our checkout- and mobile e-commerce usability studies the vast majority of the test subjects had trouble understanding various form field labels. This of course turned out to be critical in some cases when a subject was unable to make sense of a label for a required field, making it impossible for her to complete the purchase. In less severe instances the outcome was invalid data input – in some cases intentional (the subject simply filled the field with “N/A” or alike and hoped it would pass validation) but most often unintentional (due to misinterpretation of the label).
We observed that on sites without additional descriptions to the form field labels, the test subjects who were confused by a label essentially were left with one of four (less than ideal) courses of action: guessing / trial and error, visiting the help section, calling customer support, or abandoning the purchase.
Now, the solution is simple and stated in the title of this article: add descriptions to your form field labels. While this might sound easy, we’ve found that of the 100 largest e-commerce sites in the US a whopping 92% of them have “inadequate” form field descriptions one or more times during their checkout process. That is to say: it was very (very) few sites that consistently offered good form field descriptions throughout their entire checkout process.
Amazon doesn’t explain their password rules so the customer simply has to guess whether there’s a difference between lowercase and uppercase characters, if both letters and digits must be used, and so on.
Inadequate form field descriptions can be anything from sites that don’t explain their password rules (see Amazon above) to sites that don’t explain how they’ll use the customer’s e-mail address, from sites that just ask for a “CVV2” code to sites that don’t give examples of how to format your phone number.
In this article we’ll present 15 of these “common offenders” which you can use as a checklist to go over your own site and make sure you’re providing good form field descriptions to help your customers through the checkout process.
Not having descriptions for optional form field labels might not be the largest contributor to abandonments in itself since it’s not all of your customers that will need it. However, for those who do need it, it’s one of those things that can make the difference between a seamless checkout experience and a tedious process littered with validation errors, visits to the help section, and calls to support. (And if we’re talking of required form fields, the description may even be what ensures progress where the customer would otherwise have been stuck.)
Good form field descriptions are written to answer four common questions customers ask themselves when filling out a form field: 1) What is being asked for? 2) How should I format the input? 3) Where can I find it? and 4) Why do you need it?
If the customer doesn’t understand the label itself or is just unsure of its meaning, an additional description can help squash any uncertainty. The most common offenders to cause confusion are technical jargon, abbreviations, and special site / industry features:
Without formatting examples and rules, the customer is likely to run into validation errors. This is especially true of data that has multiple standard formats such as a phone number with various separators and indicators included depending on the context. Consider the following examples:
Often the customer has to type data from a physical entity such as a credit card or a letter received in the mail. In these cases, telling the customer exactly where to find that data can speed up the process significantly and reduce erroneous inputs. Some of the most common examples include:
Even if the customer know what information is being asked for, how to format it, and where to find it, the customer may still question why you need it. Consider an e-mail address field: the label is unambiguous and it’s 100% clear what and how to enter it, yet the customer may still wonder how you will use her email – will you be sending her newsletters? Will it be shared with third parties? A description can alleviate such privacy concerns. In fact, during our usability testing, test subjects have proven quite forgiving as long as the site explains why certain information is required. Other examples include:
The context of your description is crucial: it must be in the right place at the right time. But depending on the type of description needed and the design of your site, different ways of displaying those descriptions may be adopted.
There’s at least three common ways of displaying label descriptions: 1) Inline descriptions, 2) Tooltips, and 3) Dynamic descriptions.
The easiest way to provide simple instructions, formatting examples and label clarifications, is by the use of inline descriptions. Inline descriptions are typically placed in conjunction with the main label itself or in close proximity to the form field, and are permanently visible to the customer. This way help is always right where you need it.
Coastal’s address line descriptions explain what information should go in line 1 and line 2 respectively.
To avoid making the checkout form feel cluttered and overwhelming it’s recommended to subdue these inline descriptions (e.g. small grey text). Also, since they are permanently displayed these descriptions should be very concise.
Tooltips are a clever way to hide away in-depth descriptions until they are needed. Tooltips often take the form of a question mark icon or a “Learn more” link and can typically be activated by click or mouse hover (just remember to provide a proper fallback for touch devices as they have no hover state).
Amazon uses a ‘Learn more’ link to explain why they’re asking for the customer’s phone number.
Tooltips are an ideal candidate when you have to explain in detail how the information is used, why it’s required, or where the customer can find the information.
If you want to keep a very clean form design while still providing inline text descriptions, you can adopt a more dynamic approach and only reveal the description while the corresponding field has keyboard focus.
Twitter offers a good example. On Twitter’s sign up page the password rules are only shown when the password field receives focus:
Combined with inline validation, Twitter first shows you a description when the field is activated.
At Kohl’s, the phone number field is auto-formatted as the customer types. This eliminates any formatting ambiguity the customer might have had.
The example seen here is for US sites / phone numbers - you should of course always use a formatting example that match your own audience (local ways of formatting.
Form field placeholder text can also be used for short descriptions and formatting examples, although they have the inherent drawback of disappearing as the customer types. Therefore, it should only be used for secondary details such as formatting examples to avoid the trap of false simplicity.
Victoria’s Secret uses placeholder text to show an accepted input formatting for the customer’s phone number. They also have a tooltip explaining why they are asking for the customer’s e-mail address.
In this article we’ve seen the many ways in which form fields may confuse a customer. We’ve pointed to 15 “common offenders” that all benefit from a clarifying description in one way or the other. And finally, we looked at three common ways in which form field descriptions may be implemented.
Form field descriptions are certainly not the most exciting thing in this world but don’t underestimate their importance: those ultra-short contextual help texts can clear up ambiguity, ensure the customer doesn’t get stuck, and save your customer support a bunch of repeat questions.
By cleverly addressing what is being asked for, how the input should be formatted, where the input can be found, and why it is being asked for, these descriptions can answer all of the customer’s concerns at just the right time in just the right place.
Join 25,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
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 info@baymard.com
Caroline JarrettNovember 6, 2012
Your advice is always very thoughtful but I have to disagree with two of your points.
- your examples of good practice for address line 2 and phone number formatting would NOT be good practice for a UK audience. I think this once again means we must emphasise testing with people from your target audience.
- I cannot, and will not, ever accept any example as good practice that shows labels inside the field boxes. And I’m equally adamant that hints have no place inside fields either.
But please carry on this excellent series of articles
Christian, Baymard InstituteNovember 6, 2012
Hi Caroline, thank you for your comment. But I think we only disagree on “a half” of the two points you bring up:
In regards to phone formatting: sometimes we focus so much on the details that we forget to state the obvious “The example seen here are for US sites / phone numbers – you should of course always use a formatting example that matches your own audience (local ways of formatting)”. Our main point is that most of the benchmarked sites dosen’t have any kind formatting examples at all – this was merely to point out that you need to provide formatting example – not how the exact formatting should be like. I have updated the post accordingly. Thanks for pointing this out.
In regards to your second point; no form field labels should never be inline. We completely agree on that (http://baymard.com/blog/false-simplicity). I can see that at first sight the Twitter screenshot looks like we recommend this approach of inline labels (e.g. “Password” inside the label) – but the Twitter screenshot is purely meant as an example of how the description can appear dynamically when the field receives focus (the “6-characters or more. Be tricky” only appears on field focus).
The only case where we recommend using placeholder text is for secondary details such as phone formatting examples. (This might be the where we disagree). I hope the article is clear enough on that point?