This is my first Good Questions column for UXmatters. In this column, I’ll be writing about questions. When communicating with users in one direction, we typically ask them questions—often through forms or surveys. When communication goes in the other direction, we try to respond to users’ questions—both through the design of our Web applications and other products and, sometimes, in assemblies of what we hope will be their Frequently Asked Questions.
In January 2010, Janet Six’s column, Ask Matters, “Label Alignment in Long Forms,” included extensive discussion of one of the most frequently asked questions about forms design: where to put labels in relation to their fields.
Don’t worry. I’m not going to discuss labels further in this column. But thinking about labels reminded me of another question we hear from time to time: Should we put a hint inside a text box?
Champion Advertisement
Continue Reading…
The short version of my advice: Don’t do it! Hint text is rarely effective as a way of helping users, but instead becomes a default input.
Read on, and I’ll explain. I’ll start with an example, then look at the origins of the idea of hint text, and present some data that shows how hint text fails to help even highly Web-savvy users.
An Example of a Hint Inside a Text Box
I live in the UK and travel by train approximately twice a month, so I often use the UK National Rail Plan your journey form.
Figure 1—Part of the Plan your journey form on UK National Rail
If I click slightly the wrong place within the From or to text box, the helpful hint doesn’t disappear, so I end up searching for Station name / codeLeighton Buzzard, which, of course, isn’t what I want at all.
Of course, my irritation alone doesn’t make a case for a usability policy. So let’s look into this a bit deeper.
Where Did the Idea of Hint Text Come From?
In the original Web Content Accessibility Guidelines, WCAG v1.0, you’ll find this checkpoint:
“10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.”
That was back in 1999. The problem was that the screen readers—the most typical example of a user agent—available then didn’t do well with forms. There was no label attribute. Few Web design patterns existed. Screen readers had to muddle through forms as best they could.
More than 10 years later, user agents do now handle empty controls correctly. Web designers have become more accessibility aware and use the label attribute. There is no longer any need to put hint text—that is, “place-holding characters”—within text boxes for accessibility reasons.
In fact, the current accessibility guidelines, WCAG 2.0, no longer mention place-holding characters at all.
Why Are Web Designers Still Providing Hint Text?
If putting hint text inside text boxes is no longer important for accessibility, why do we still see this so frequently on the Web?
I think it is because form designers want to be helpful. The general idea is that the text gives users a hint, helping them to know what type of answer goes in the box.
But Text Inside a Field Tells Users: This Field Is Filled In
In 1999, Jakob Nielsen created “Jakob’s Law of the Web User Experience: Users spend most of their time on other sites.” [1]
That’s still true today, and it has an important corollary: Caroline’s Law of Forms User Experience: Users fill in other sites’ forms more often than they fill in yours.
As users work through most forms:
They see a blank box.
They type.
The box now looks filled in.
Each time this happens, users learn that
boxes they need to fill in are blank
boxes with text in them are already filled in
Every time users get distracted from a form, then go back to finish it off, they use that piece of learning.
Every time users encounter a form that has some defaults filled in, they use that piece of learning.
So, what the hint text tells users is: This field is filled in. Therefore, the hint text becomes the default text.
“But Caroline,” I hear you argue, “what about all the hint text users see on other sites?”
To which I reply: Users don’t encounter hint text frequently enough to counteract the lesson that a box with text in it is already filled in.
For example, I was testing a form that was part of an accountancy package. Participants in the study had to create two records for new customers—let’s call them Mr. Smith and Mr. Jones. As I watched the first participant, he opened the appropriate form. The first field had the label Customer name and the hint text New customer. He skipped right over that field—because it was already filled in—filled in the rest of the form with Mr. Smith’s details, and clicked Send, creating a new customer record. This worked, so next he tried repeating the same actions for Mr. Jones. This time, that failed, because he’d tried to create another record with Customer name:New customer. As is usual with usability defects of this type, I then had to endure seeing participant after participant make exactly the same mistake.
The Numbers Confirm That Hint Text Tells Users: This Field Is Filled In
Do I sense a note of skepticism? Are you thinking: “That’s all very well, Caroline, but your participants in that test might have been especially naive?”
I had that thought, too, so was delighted when I recently had the chance to get some better data about this issue.
I was having a chat with some scientists at EMBL-EBI about one of their forms. Research scientists worldwide use this form to submit jobs to one of EMBL-EBI’s suite of online scientific tools. (I’m not going to try to describe what the tool actually does: they did tell me, but only the words then, and, and settings made sense to me.)
It was fascinating to hear about how the EMBL-EBI designers had tackled their form-design problem—taking a classic user-centered design approach to find out how their target users thought about the form and how they used it. They had done lots of usability testing. As we worked through the form, I kept asking “Why did you do that like that?” They were able to justify their decisions straight away.
But they still weren’t quite happy with how they had handled a couple of items—hence our chat. I loved having the opportunity to discuss this form with such a thoughtful team.
Then I happened to notice that the form included some hint text, My sequence, as a suggestion for JOB TITLE, as shown in Figure 2.
Figure 2—Another example of hint text inside a field
So I asked the EMBL-EBI designers whether their scientist users recognized the hint for the JOB TITLE field, My sequence, as a hint, overwriting it with their preferred text, or as a default, skipping over it to fill in the next field.
They said: “Our users haven’t had any problems with that. But we do get a lot of jobs with the title My sequence.”
They also said: “Give us a few days, and we’ll check on this for you.”
A few days later, back came the figures. Over a typical 24-hour period, they received 9,669 non-email jobs. 9,511 had the title My sequence. That means, in 98% of those jobs, the user had treated the hint text as a default.
Their email message said: “These numbers are extracted from a small sample that is not indicative of total usage.”
“Fair enough,” I thought. “I’ll ask them to check again.”
This time, during another 24-hour period, they had 17,336 jobs. Of those jobs, 17,121 had the title My sequence. That’s 99%.
Putting this another way: all but 1% of the form’s users interpreted the hint text as a default.
Even Frequent Users Go for the Easy Option
The EMBL-EBI designers were still a bit concerned about whether these samples were really representative. They pointed out that some users submit more than one job. Also, users could opt to provide an email address and receive notification of the results by email as well as in their browser—a useful feature for repeat users who submit many jobs.
So they looked into the figures some more. We expected that users opting for email notification would be more likely to choose their own job title, and, indeed, they were. Of the 232 jobs using email notification, only 139 had the title My sequence. That’s only 60%.
But I said: “Wait a minute: 60%? That’s still a really big proportion. And these are your most sophisticated users—those who are very familiar with this form and its features.”
The Underlying Lesson
If you include hint text inside your form’s text boxes, many users—quite likely, the majority—will interpret the hint text as a default. If that’s what you want, go right ahead. Otherwise, think of another way of helping your users.
How about putting an ellipsis (…) after the text in the box—like in Email…?
How about validating for My sequence in the example above?
It’d be great to look at some data on how properly designed text in a text box works.
I agree that one should try to avoid text inside the boxes, but if you follow these simple rules for designing it, it might save you some space and provide an extra bit of help for users.
It’s also a shame there’re so few bug-free implementations of the grey text out there.
It’s an important question, but I think there may be other factors at play in your examples.
The National Rail form failed because it did not correctly remove the hint from the field when it gained focus, not because the hint looked like a default value. (There isn’t a station called Station Name / Code.)
In the EMBL-EBI example, there was no confusion: My Sequence was the default value, not a hint. If it was not an acceptable value, it was up to the form validation to alert the user to the fact. There is no way of knowing how many of the 99% simply preferred to keep the default rather expend the effort of coming up with a new name for the job.
It seems to me that the hint was either badly worded—perhaps Enter a memorable name for your job would have been better—or maybe just unnecessary. The label is descriptive enough.
In both cases, it would have been better for the hint to be a separate element that was styled—using some unobtrusive JavaScript—to appear over the input field and disappear when the field gains focus. Then there’s no chance of it’s getting submitted with the rest of the form, but it still provides valuable guidance to the user about the expected value for the field.
I agree with this article about the improper use of hint text in Web forms.
However, I think some of the issues discussed here—such as the National Rail site—sound like defects of improper hint text usage. Hint text should always disappear once the specified control gains focus—that is, the user can enter text into it—regardless of where the user clicks it.
Secondly, there are other design patterns that make good use of hint text—such as search text boxes especially in areas of confined real estate. For example the Quick Search box in Firefox displays hint text showing the current search provider—for example, Google or Yahoo.co.uk—and this always disappears on gaining focus.
I can understand hint text’s confusing users into thinking it’s default text, if the hint text looks exactly like regular text within the field—for example, in your Figure 2. I would be curious to know what the numbers show when the hint text is restyled.
As far as the hint text’s being submitted as a default, that sounds like a poor technical implementation. Tell your developers to stop doing that.
I agree and disagree. What about having hints with a different color—for instance, a light gray that clearly shows it’s not a default value, but informative text—that is, hint text? I would be very curious if the report wouldn’t switch to a 50–50 or even completely switch to 99–1 in favor of hints.
I know that, from my Web experience, I have always typed in the fields that had a light gray hint or no gray at all. But I am a Web developer, so that might be one issue. :)
Anyway, perhaps if the color is an issue, you should rename the article to something like “Don’t put hints inside text boxes without styling them accordingly in Web forms”?
Thanks for the article and for the statistics and information!
Great article. Like some others have said, I think people are just trying to save space and prompt people to enter the right content. Personally, I think it is more elegant than having ToolTips at the end of a design, but as you say, it’s still not an ideal solution.
I think the problem is often a lack of usability testing as well—people often don’t realize which parts of their sites are logical or illogical and hence don’t quite know how to design it properly. We’ve recently designed our own usability tool at IntuitionHQ, which we find quite helpful in this regard, and there are plenty more out there on the Internet as well.
The key is just putting everything together in order to make a great design.
Thanks all for your discussion. I’ll aim to respond to your comments one at a time:
hansenly: You spotted it! The logo is deliberately a bit ambiguous: is the text a question or an answer? My hope is that it’s intriguing.
useuseuse: I’ve seen hint text being misinterpreted in various designs. Do you have some data that you could share that shows that your participants interpret your suggested designs correctly?
dan: It’s interesting that you interpreted My sequence as a default value, just as the users are doing. That wasn’t the designers’ intention. As I mentioned in the article, the text didn’t actually inconvenience the users or cause them any problems. It just didn’t work the way the designers thought it would.
Karim Toubajie: I’d like to see some comparisons between Search boxes without any hint text in them, and those that do have some hint text—even if it is faded and then disappears. My impressions from oberving users is that they take a little longer to identify the Search box as such if it has hint text in it.
Andrei Gabreanu: Your point about Web developers’ understanding these subtleties is spot on.
I did consider giving more equivocal advice about styling, but rejected it, because I don’t find that styling really helps enough to overcome the basic problem.
I agree with the comments above—National Rail didn’t do an adequate job of getting the embedded Help to remove when the field has input focus. And, different design and wording could have likely better communicated that the Job Title in the Job form was not intended as a default.
Given your comments that users will skip over a field if it looks filled in, it would be really interesting to see if that still holds true with some subtle design changes—for example, light gray text. In your testing of the accountancy package form to create a new customer, how did the embedded text look?
I do feel that the embedded hint text is no substitute for a descriptive label. In your accountancy package example, if users were filling in a New Customer form, seems having a label of Customer name alone would be plenty obvious.
I think these are just poor examples of using in-field labels. The images shown clearly make it look like it’s a default value. A little bit of design would go a long way for these forms.
Several other things, if you choose to do labels this way:
Validate, server side, that the value isn’t the default value.
Make the text grayed out so as to make it look like helper text, not like the other inputs with a darker shade.
Make the text disappear.
Better yet, test this interface with a much cleaner implementation—and that is using CSS, JavaScript, and labels, and progressively enhance the forms. me.com is an example of this. You are using the field label, positioning it over the text, giving it a lighter shade, then using JavaScript to hide / show when people click the text field. It also has the advantage that the text doesn’t immediately disappear—it simply fades to a lighter color, so the user can still see the Help text before they type.
You don’t have to validate anything, because it’s not actually the value of the field itself.
It works even with password fields, which would normally only show asterisks.
I just don’t think you can say ‘Dont do it!’ when the examples presented are blatantly poor examples of in-field hints.
In practice, hints in text fields can have utility, but you’re right that when improperly implemented they do more harm than good.
The typical practice of prefilling the form field and then using JavaScript to remove the text when gaining focus is flawed. It fails to provide progressive enhancement, does not degrade gracefully, and as you note, is prone to bugs. Not validating input against the hint text further compounds the issue.
My preference is to use CSS to provide a custom background with distinctive hint text rendered as an image, provide a blank background for the focused meta-class, and use JavaScript to clear the background once text has been entered. It doesn’t provide any benefit for accessibility, but it does prevent the hint from doing damage, and it degrades gracefully.
I think the issue at hand is more of implementation than of the use of hint text.
First up, help text should always be implemented as a progressive enhancement, allowing for behavioral control over the visibility. My recommendation would be to use your JavaScript of choice—framework or otherwise—to populate, on document ready state, the assisting text.
Second, the text itself should not have the same shade as entered text—browser location and search bars are good examples of where they have been used well, as Andrei has mentioned, where it is a light shade of grey. Possible other means of identifying help text is through the use of italicizing the contents.
Third, the help text, only, shall be removed on focus and only reappear on blur if there was nothing entered into the input / textarea.
Fourth, feedback to the user—preferably a modal window—triggered by a behavior-based check of the form, should be made available. Where the help text is still present, the user should be notified.
Finally, any and all help text shall be removed prior to the form being sent—to ensure non-required fields are not incorrectly populated.
This is a really interesting article. I wonder, Caroline, do you not think the examples above could have been helped by having the E.g. prefix?
When I have included hint text in the past, I’ve always found you need to have the E.g. or a secondary label as hint text Please enter a numerical value…. Otherwise, the hint text definitely does look like it’s just an answer.
So many interesting comments that I’ll try to reply to all of them in one go. Thanks for making this a great discussion.
I know that the placeholder attribute is appearing in HTML. But having an attribute in HTML isn’t the same as making it a helpful feature for users. Example: Reset. Can be used; shouldn’t be used in most cases. I wrote an article about that a few years ago: “Reset: the piece of HTML created just for me.”
My contention is that the main problem with hints inside text boxes is that users don’t realize that they need to fill in a box, so they don’t click the box.
Having the text disappear when a user clicks the box doesn’t solve that problem.
Removing the text on submission then either creates a blank field in the database or gives the user a validation error that is unexpected. Neither is desirable.
And being a little mischievous: the implementation subtleties that are being suggested to make the hint appear less obvious, move away, and so on seem like a lot of work to me compared to just not putting a hint in the box in the first place.
“And being a little mischievous: the implementation subtleties that are being suggested to make the hint appear less obvious, move away, and so on seem like a lot of work to me compared to just not putting a hint in the box in the first place.”
Being a little mischievous: UX—as design in general—is always also very much about implementation subtleties. Every idiot could get the ergonomic basics right nowadays—it’s detail that counts and sets a great experience apart from the great mass of bad to mediocre ones. Hence, implying that care for detail involves more work than doing an, at best, mediocre job seems pretty pointless to me.
Definitely agree with you that implementation subtleties are important in UX.
Only, I’d take the view that one of those subtleties, and perhaps one of the most important, is to simplify—and sometimes that means not implementing something.
Which also has the advantage of saving a bit of development time to be devoted to something else—perhaps more testing with users.
I’d just like to point out that the example you used, the National Rail site, is simply a matter of poorly coded JavaScript.
The event handlers that are supposed to deal with the hint text are assigned only after the whole of the page has finished loading. The problem with the National Rail site is that it has so many slow-loading resources like Flash that the text boxes are visible on the page a long time before the event handlers are assigned. If you wait for the page to load, then everything does indeed work fine.
The examples you show have both hint text and labels. I’ve developed forms with no labels and have treated the hint text as noted by others—grayed out, disappearing when appropriate, and so on. The benefit is a cleaner, simpler layout, less eyetracking from label to field, and less ambiguity about what the user is to input.
That said, if I saw hard evidence that forms designed as I suggest actually have a higher failure rate, so I’d ditch hints and revert to labels in a second.
James: Thanks for taking the time to explain why the National Rail site works the way it does. I chose it because it’s an easy-to-understand example that is available publicly. As I mentioned, it illustrates a problem that I’ve seen across many forms—on and off the Web, coded well and badly.
A note on the implementation of hint text that is based on the examples you gave and some of the comments made …
Hint text should never be set as the value of a text field.
The optimal implementation for hint text has the actual text as part of the label. This text is then positioned over the field in question and event listeners (focus, click) set so that it disappears when the field gains focus or has a value. This avoids the problem of the hint being submitted as a default value.
Of course, this doesn’t address the issue as to how usable hint text is. I leave that to UX people. (I’m a front-end developer.)
It must have been a slow news day or something, because the fact that this article was posted in the first place seems a little silly to me. The blanket decree, “Don’t Put Hints Inside Text Boxes in Web Forms” contradicts research data and common sense.
There’s a time and place for this approach, and as others have eloquently pointed out, the implementation was the problem in Caroline’s example. A solid implementation of in-context Help or hints will always contribute to a more productive, persuasive, and delightful user experience.
Maybe I’m just feeling cranky this morning, but I think this article actually reduces UXmatters’ credibility in my mind.
Your point about not having labels at all is really another whole topic—in my mind, anyway. Perhaps you could mention some examples of forms that use this technique that you consider to be well designed?
Patrick:
The problem is of having anything in the field—that’s what makes it look filled in and means that some users will skip right over the field—so anything that relies on them clicking the field to make the hint go away won’t work for them.
Hiran:
Your point raises another whole topic for discussion—that is, if you can’t put the hint into the field, where should it go? Another one I’ll leave aside for the moment.
Thanks, Caroline, for a thought-provoking post with some really fascinating statistics!
I’d be happy to be convinced otherwise, but it seems to me that an approach that will work for everyone is to provide the question in the label and any hints, tips, or examples immediately below the field, like Twitter does.
This doesn’t require any Javascript or other such trickery, means all the information is available at all times to the user, and I think is the most accessible approach, for those with and without a disability.
@Hiran
Alas, I think a ToolTip is not very accessible.
You need to be using a mouse to trigger it—bad luck if you’re zipping through the form with your keyboard—and I’m not sure whether it would be read out by a screen reader. More generally, using a ToolTip means the information is hidden with no cue to the user that it is there.
@Michael McWatters
I would strongly argue against using hint text inside the field in lieu of a label, as this is also not very accessible.
For those people using a screen reader, the label is how they know what the question is. For those people not using a screen reader, you have the problem that as soon as they start typing in the field, the “label” is gone. If they want to see it again, they have to take out anything they’ve entered. And when you’re looking at the completed form, you’ve got no way of knowing whether the information you’ve entered is right.
Given all that we know about how people move through forms, including the eyetracking research published here on UXmatters, I don’t see that there is a problem here to be solved by getting rid of labels. This approach might give the form a “cleaner, simpler layout,” but to me that’s at the sake of usability, like getting rid of the side- and rear-view mirrors in a car to make it look more streamlined. The saccades between the label and the field can be very minor if these items are aligned well, and I would argue that, in providing less information, you’re actually making the form more ambiguous, not less.
A lot depends on the context of the form, the data being collected, the purpose of the data collection, and the layout and design of the form itself and the surrounding content.
As an example in a recent WhichTestWon test,
the required conversion was the completion of a form.
One was a typical form with labels on the left of the fields and the other a multicolumn form with field hints and a minimum of labels—the latter of a layout and style generally believed to reduce conversions.
One of the forms increased form completions by 16%. Guess which?
It’s far too simplistic and proscriptive to just say never!
As you point out in your post, the winning form was completely redesigned in many ways. As the comments on that winner point out, the changes included
making the form look a lot shorter
putting the Continue button above the fold
and a whole bunch of other changes
I’m not disputing that in a head-to-head between those particular forms in that context with those users, the form with the labels inside the boxes won.
I would strongly dispute that this necessarily makes putting labels inside the boxes a good idea.
But either way, as I said in a previous comment, this column was about putting hints inside the boxes. Putting labels inside the boxes is a whole other story—and one I’ll think about writing about.
Maybe I have mistaken, but when I enter this site, there is a bar appearing at the top where there is a text box with the text Enter topic to look up inside. Does that directly violate what you have discussed in your article?
Sounds like you might be outnumbered by developers here. As another usability engineer, let me ask the other posters a few questions:
What do in-line instructions get you? I’m guessing saving space here—a fine thing to shoot for, though not the be-all and end-all of Web usability.
Does this benefit come with any cost? And I don’t just mean theoretically either. Caroline’s already shown one real problem that real users have with these, a problem that I’ve seen myself. Actually, though, I’ve seen another problem even more: users clicking the field without looking, effectively making their instructions disappear.
Does the benefit outweigh the cost? Having watched users struggle with the issue above, my opinion is, in general, no.
Note that the only real problems I’ve ever been able to see in the lab are when the in-line instructions take the place of a label. Can’t say a lot about when they’re simply additional. My guess is, in that case, they’ll probably be unnecessary—there’s not enough space to say more than is effectively said in the label. And if there is, it really needs to go in something like a help link.
Thanks for adding to the discussion. Maybe some of the other commenters will jump back in with more rejoinders to your points, but I agree with them myself.
I have deliberately not delved into the question of putting labels inside the boxes. I have to say that it seems barmy to me. But I have yet to test a form that does that, and I haven’t been able to find any published study or get any evidence one way or the other. When I do, I promise I’ll publish here.
My bad. I’ve actually seen both. My guess is the ones without labels are just so glaring that they’re the ones I remember. And, yes, they’re out there. For example, just check out the branch locators on the home pages of 5/3, Key, and Huntington banks (US). And, yes, they do not test well at all.
I disagree with the evidence from the EMBL-EBI about the default text My sequence being interpreted by 99% of users as a default job iitle and that it should be left. If the hint text itself contained something that was more abstract in and of itself, such as the text Job Title, a user might be more likely to change it.
However, I am inclined to believe that hint text might be better, if it were explicitly set as part of the label itself, so it doesn’t disappear as hint text inside an input box would and so it makes for an easier user experience all round.
I would like to suggest that, for any text-entry box that would require a hint as to what a user should enter into it, we should instead change the label to make it unambiguous.
In this very form I am filling in, it asks for Your name. No hint is required.
In the rail travel example in the article, hints are needed because from and to are not explicit enough. No hint would be needed had it read:
Plan your journey:
Enter the station name or code of the station you wish to depart from [Text Box] and the name or code of the destination [Text Box].
I say again, if the question being asked requires a hint as to the answer, you are asking the wrong question.
Enter some numbers here requires a hint, Enter your mobile phone number does not.
I also detest hints in text boxes. I am always trying to select the hint with my mouse so I can then hit Delete to clear the box and type in my own text. I just wish there was a way to tell my browser (Firefox) not to display hints in text boxes.
I find it an absurd notion that just because form hints are not found on other sites they should not be used on your site. It’s absurd because, if this law were applied to everything, nothing would be improved upon. If Apple did whatever everyone else did, we would still be looking at black screens and typing in green characters. What a ridiculous article.
Furthermore, these example are poor. For instance, the New customer is easily the fault of the developer/designer not the concept. For Customer Name: the hint should have been “i.e. Tom B. Jones.”, New Customer. All hints should be in faint grey color and preceded by “i.e.” Just putting some text in the same hint, color, and size will naturally confuse people. Don’t throw out the baby with the bath water.
The Web is riddled with bad examples of good concepts. Don’t perpetuate that by dismissing good UX concepts. I’ve been on plenty sites where the label was misleading and could have used a good hint as to what they wanted.
If I’m not mistaken, these prompts inside text fields are not compatible with Web readers for the visually impaired.
I’ve also seen cases where less savvy Web users were hesitant to click inside a field when they saw something in it. But you can always put a prompt message inside a TITLE tag and use that inside a text field. That way, the text appears as a ToolTip once the field is in focus, or selected.
If you need an extra prompt, perhaps your labels aren’t doing their job well.
Caroline became interested in forms when delivering OCR (Optical Character Recognition) systems to the UK Inland Revenue. The systems didn’t work very well, and it turned out that problems arose because people made mistakes when filling in forms. Since then, she’s developed a fascination with the challenge of making forms easy to fill in—a fascination that shows no signs of wearing off over 15 years later. These days, forms are usually part of information-rich Web sites, so Caroline now spends much of her time helping clients with content strategy on huge Web sites. Caroline is coauthor, with Gerry Gaffney, of Forms that Work: Designing Web Forms for Usability, the companion volume to Ginny Redish’s hugely popular book Letting Go of the Words: Writing Web Content That Works. Read More
you’ll find this checkpoint:
