When I first started working in user experience design, the thought of designing a form filled me with dread. It’s something that seems like it would be so easy, but creating a really good form requires a lot of thought (which is why poorly designed forms still abound). Many Web conventions exist around form creation, but that doesn’t mean that they always make sense. One of those conventions is the required field indicator.
Luke Wroblewski, the master of web form design, devotes several pages of his book Web Form Design: Filling in the Blanks to the topic of required fields. He argues that there should not be an absolute rule about marking fields as required or optional, but that the more important question is whether to indicate anything at all. If you have a form where all fields are required or all are optional, Luke says that indicators aren’t particularly useful and are actually unnecessary information that users have to pause and consider.
This guideline does not sit well with some people, who have seen enough required field asterisks on forms to think it’s important to indicate all required fields no matter what. But thought through, this typically is not necessary. Take a login form, which typically shows two required fields. These fields really do not need to be annotated in any way as required – the form is short, the necessity of completing the fields is relatively obvious or quickly learned through experience (click Login and get an error). The recovery process associated with the error of not completing a required field is not terribly painful for the user. Moreover, as more and more applications are designed for smaller devices, it’s a good time to question every additional element you add to a screen.
In longer forms, an overriding guideline is either to try to drop fields that aren’t required to make it easier for users to complete a form, or to group all optional fields on a separate page or panel so that they are more easily passed over by those who don’t want to complete them.* If the form is distilled down to only what’s really necessary to complete the action, it shouldn’t be so long as to cause a lot of users significant confusion about what they should or should not enter, and again the error recovery process is minimal (provided none of the data they did enter is cleared). If the information makes sense for the task–e.g. asking for a credit card number and address for an online purchase–users aren’t likely to assume they don’t have to complete the fields.
When you do have a form that has includes both optional and required fields, he suggests adding indicators to the field type in the minority. So, if the form is mostly optional fields with a couple required, annotate those, and if only a couple are optional, annotate those instead. As for how to annotate them, he questions the assumption that an asterisk means required, showing examples of some forms that use the asterisk to indicate optional fields. He instead suggests that being explicit is best: literally include the word “optional” or “required” after a label.
One final guideline he offers: if you do decide to use an asterisk to indicate something, don’t align it with the input fields, but rather with the field labels. This makes it easier for users to scan a form to see which fields are required.
What do you think? Have you tested a design without annotations that confused users? Is this a good guideline?
* Some psychological factors may come into play in trying to encourage users to provide optional data that might actually help them down the road (personalized experiences, for example) that may impact form design as well. So, as with all guidelines, there are exceptions.
Marking required fields on forms: should you or shouldn’t you?
by Molly Malsam on June 22nd, 2011 | ~ minute read
