As previously mentioned, user experience practitioners often rely on common sense, convention and past experience when making design decisions. Usability research may seem like overkill, but even when you’re sure of your assumptions, it’s always good to double check.
For instance, Luke Wroblewski once wrote an article in which he provided some very sensible guidelines for Web Application Form Design. Matteo Penzo and the folks at UX Matters decided to run some usability tests on the subset of those guidelines that dealt with label placement. The findings were not entirely in line with Wroblewski’s assumptions – a discovery which he apparently took to heart, since he later performed his own usability tests regarding primary & secondary actions. These tests were preparation for his recent book, Web Form Design: Filling in the Blanks (which I will probably have to purchase now that I notice how interesting it looks). What follows is a results summary for both of the aforementioned studies, for quick reference.
Label Placement
- Place labels above the input fields where ever possible. Leave adequate spacing between each label-field pairing.
- If you must place labels beside (to the left of) fields, right-align them.
- Make sure the visual weight of your labels does not compete with that of your fields (bold labels conflict with the default field styling).
- Drop-downs are distracting. Place them after more important fields. Use the default item in the list as the field’s label.
Primary & Secondary Actions
- You can minimize form completion time by aligning primary actions with input fields.
- When you have a form with a primary action (ex. “Submit”) and a secondary action (ex. “Cancel”), style the secondary action with less visual weight.
- Users prefer error prevention over decreased form completion time.
- Don’t include secondary actions on a form unless you actually need them.
One thing I wish they would have tested in the label placement study is putting labels inside the form fields. These labels would disappear when a user clicks to input data in that field. Ideally they would reappear if the field loses focus and is not yet populated with data. This technique saves screen real estate and makes for a cleaner design.
The primary & secondary actions study revealed an interesting preference on the part of users: they’d rather be prevented from making errors, even if it means sacrificing a bit of time. This could be a point in favor of inline validation/contextual help. Usability research on these techniques would likely yield highly valuable results. One question that immediately comes to mind is whether real time or on-submit validation is preferred.
Do you know of any recent studies about compact form labeling or inline validation? Have you discovered or conducted any usability studies of interaction design topics? What topics in user experience do you want to learn more about?
5 Comments
The really crucial point that you make is this one:
“an interesting preference on the part of users: they’d rather be prevented from making errors, even it if means sacrificing a bit of time”.
In our book on forms: “Forms that work: Designing web forms for usability”, we discuss inline validation. It’s great if it gives users polite, accurate feedback when they have finished putting in each entry. It’s seriously annoying if it starts to comment on their typing before they’ve had a chance to do what they need to do.
The difficulty with compact form labeling is that users look for ’space for me to type into’ when they come to a form, and then they look left (and then above) for the label that tells them what to do. If the label is _inside_ the field, then there is a definite possibility that they won’t realise that typing is necessary. I have seen users repeatedly make the same mistake on this.
The advice you have summarised on where to place the labels is sort of correct, but not completely. It depends on the type of questions. See my article “Label placement in forms” http://www.usabilitynews.com/news/article3507.asp
Best
Caroline Jarrett
http://www.formsthatwork.com
Caroline,
Thanks for your comment! Please accept my apologies that it didn’t appear on this post instantly. For some reason it went to my spam queue, but I’m glad I discovered it.
I agree that inline validation could seriously derail the user’s momentum with its interruptive, dynamic and thus distracting nature. As with most interface design patterns, it’s one to be applied with care and deliberation.
The main thing that concerns me about compact labeling is that the label disappears when the user starts to type. What if they forget what the label said? And like you suggest, what if the field’s styling fails to afford input?
Your article does a good job of explaining how the general summary I gave here can be applied in a wider variety of situations. The findings of one study can be a helpful guide, but shouldn’t be applied to every situation indiscriminately.
So in short, I totally agree with you.
Yes, Poorly written forms are annoying – visitors hate forms, hence poorly validated/written forms only help to irritate users – use legends, tip boxes, enable radio button text not just the buttons – and if you have validation tell the user exactly which fields need correcting and whatever you do – do not loose data that has already been entered – that is just plain infuriating.
but this is only a fraction of the picture you might want to take a look at this blog for a bit more info http://www.vuzudesign.com/web-design-blog.php
Thanks Chris.
Visitors may hate forms. But that’s kind of inspiring – how can we make forms not just usable, but enjoyable?
Granted, efficiency is often a priority, but there are still many cases where completing a form could be a pleasant and even delightful experience.
Thanks for providing information regarding “Designing Web Forms – Label Placement & Primary vs. Secondary Actions”. I got a plenty of information from your site.
2 Trackbacks
[...] and "Fancy Form Design Using CSS" will help you with CSS form layout. Read "Designing Web Forms" and the pages it links to for info on designing forms. Protip: use [HTML] and [PHP] rather [...]
[...] [...]