Caroline Jarrett, usable form guru, gave a 45-minute talk on “Label placement in forms (and other time-consuming controversies)“, over at Microsoft Research. She was introduced by Carl Myhill, who helps to coordinate the Cambridge branch of the Usability Professionals Association (UPA). There was time at the end for a few questions, and Caroline was joined by Steve Krug, who had popped up from London, where he is holding a workshop this week.
Just for the uninitiated, I thought it might be useful to explain some of the simple bits of HTML forms, which is what we are talking about here. The term “label”, for example, refers to a specific part of form structure.
Above is the log in form for a WordPress blog like this one. I have annotated a few of the key features, including the labels – the things that describe to the user what a form element (usually a text input box) are for.
If you are marking up your forms correctly (or if Dreamweaver is doing it for you), then the text of that label will sit inside HTML <label> … </label> tags.
So, with that little Form Labels 101 out of the way, onto the talk. I found the slides for this talk on SlideShare, so here goes:
Does it matter where we place labels?
Yes, it does matter, but every case is different, and you need to a) be sensible, and b) test for usability. Essentially, don’t get hung up on the minutiae of “oooh… should we have a colon a the end of the label?”, to the detriment of the rest of the project!
As demonstrated in eye-tracking tests, people strongly focus on the left-hand end of input boxes, where they will being typing, and often completely ignore the right-hand end. Clearly, placing labels for forms on the right won’t do much good.
We were shown a number of eye-tracking heatmap images to illustrate this point, and we also discussed Mario Penzo’s form recommendation (“place labels on above or to the left, right-aligned”). It became apparent that often the issue of WHERE the label is placed is not as important as the TEXT of that label, and the question you are asking of the user.
In terms of how we write those labels, then people generally find it easy to read what is familiar to them. So keep it succinct, and use sentence case.
It should also be noted that people have been shown to satisfice their way through forms, and will often barely read the trivial bits (name, address, etc), and just scan through. Users probably won’t use your carefully crafted form (or even the rest of your website!) in quite the way you expected!
Think about what you put on buttons – the text should explain what clicking that button will do, e.g. “Log In” in the example above.
Unless you have an overwhelmingly good reason to have a Reset / Clear Form button in your form, leave it out!
Beware of apparent or false ends in forms, particularly ones that are complex and/or spread over multiple pages. This can be a killer. The example in Caroline’s slide #28 showed part of a form where the thing that the user should click to submit their form was actually a hyperlink, and not the standard submit button. D’oh! Not good.
In terms of form labelling, and the sequence of interactions a user makes with a form, Caroline used the useful metaphor of a conversation.
In this case, both the user and the computer (the form on your web page) should take predictable “turns” in the conversation. So, it is a bad idea to have the form just do something that the user didn’t expect – that is like an interruption or a complete change of subject in a conversation, and degrades usability and the user experience.
Q & A
There were several questions from the audience, and Caroline was joined by UX guru, Steve Krug at this point.
A few of the questions received the same essential answer – if in doubt, test it with your users as part of the design process. There were many good points, and some useful discussion.
So one guy asked which appeared to be better: having “Password” or “Enter your password” as a label.
I asked for their opinion on the kinds of form where form elements appear (or even disappear), or are only activated, when the user provides particular input, or has completed a given section. Often (but not always), these kinds of forms will use AJAX to make immediate changes to form content.
Martin Lucas-Smith made the good point that, while those sorts of AJAXified forms may work well in some [simple] cases, they would probably do more harm than good in complex forms, where ther might be a lot of branching (possible routes for the user to follow).
Tim Regan also pointed out that the UX of those kinds of forms, where they do rely on AJAX to get data from a database, can often suffer if they are a long way from the database, or have a slow connection. They have to wait for the form to update, essentially.
On the point of branching and complexity, Caroline told us that her studies have shown that users are actually happy with multiple pages of appropriate, short questions. This approach is robust, and allows the user to see that they are following some sort of path.
In these cases, it is good if the user (or the web page, automatically) can save their progress as they go along. In addition, some sort of ‘wizard’ at the beginning of the form process may allow for the construction of a suitable complex form, and make things more usable.
Woo hoo! Steve Krug answered my question! 🙂