Don’t put hints inside text boxes in web forms

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?

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.

Plan your journey form

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’ (Do Interface Standards Stifle Design Creativity? Alertbox, August 22, 1999).

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:

  1. They see a blank box.
  2. They type.
  3. 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 scepticism? 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 below.

Example of hint text in a field

So I asked the EMBL-EBI designers whether their scientist users recognised 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.

This article first appeared in UX Matters, March 21, 2010