Designing form fields: Optional versus required
Julie Grundy is a senior UX designer at Bronto + Oracle, a cloud-based commerce marketing automation platform based in the USA. The president of Triangle UXPA and co-founder of Ladies that UX Durham, Julie is a big advocate for structured content. Ahead of her presentation at UX New Zealand 2017, Julie shares her thoughts on using optional and required fields in form design.
Forms are critical to online interactions. They provide the two-way digital communication needed to grow a contact list, leave a comment on a blog that talks about research in an agile environment, book an Airbnb, teach the world sweet uke skills via YouTube, register for classes, and so much more. A form is also often a road block between the user and the information they are trying to get. It’s important to make the forms as efficient and easy as we can.
So if you’ve ever left a comment on one of uxmastery.com‘s blogs you probably know what this symbol (*) means. Asterisk. It’s sometimes red. It means required, right? Well, the little asterisk can cause communication issues. And as designers, it’s our job to do what we can to help prevent issues.
I’ll be sharing some key tips for how to design an effective form at UX New Zealand 2017, but for now I want to focus on the often overlooked required versus optional debate.
Mark fields as optional, leave required fields note-free
Well, I got right to the chase.
Luke Wroblewski wrote the book Web Form Design in 2008 and clearly laid out guiding principles for form design. On this topic, he writes on page 78:
“Literally including the phrase ‘optional’ after a label is much clearer than any visual symbol you could use to mean the same thing. Someone may always wonder ‘what does this asterisk mean?’ and have to go hunting for a legend that explains things.”
Why should we mark fields as optional and not required?
There are probably more reasons than this, but here is where I’ll start. Please comment below if you think of any more.
- Clearer communication: As mentioned above, not everyone knows what the red asterisk means. “Optional” is written in the language of the form. The asterisk is requiring the brain to do additional processing.
- Most friendly: Using language like “Optional” is letting users know they have a choice, which is inline with the Norman Nielsen Group usability principle of user control and freedom. As we see trends towards online personalization, remember that anyone can make their form a little nicer.
- Less visual clutter: The asterisk is a design element that is cluttering up a form. It’s taking away from the goal of filling out the form. Chances are the majority of your form fields will be required so only needing to mark the optional ones takes up less real estate.
- More logical: It’s expected that fields are required. If someone is filling out the form it’s because they expect something afterwards. Fields on original paper forms were all considered to be required. There is a purpose to filling out the form or people would never do it. (Although, I’m sure this purposeless form happens more than I’d like to know. That’s a topic for a different day.)
Why do we see “required” so widely used on forms?
The required attribute comes from form code. Regardless of whether you’re in XHTML or HTML, the decision for “required” needs to be made in code.
So it makes sense why we would see it reflected in designs. Though, let us remember that concepts that spur from the development team do not have to be what we, as designers, default to for the front end.
Some practical tips for form design
Add (optional) at the end of the label
The best way to indicate optional is to add the word in parenthesis after the label. It’s easy to read and visually connected to the label that it is referring to.
Style (optional) in a slightly lighter color
Giving “(optional)” a different, less prominent color will give visual distinction between the label itself and the friendly directions.
Use well-written inline validation if a form field is required
Inline validation is when inputs are checked as the form is being filled out, not after the form has been submitted. This helps decrease errors and provides an opportunity to give direction along the way.
Keep in mind that clear language needs to be used for the validation. Phrases like “invalid symbol” and “This field needs to be filled out” are less clear than “Please only numbers” and “Please enter a valid email address.”
It’s also important to not display inline validation in real time as it will often show an error message before a user is done completing the field.
Add intro text to the top of the form
Adding a short piece of intro text can help clear up any outstanding issues. Intro text should include:
- Reason why someone will fill out the form.
- Instructions. If and only if you are nervous about switching to marking optional instead of required. For example, “all fields are required, except ones marked as optional.”
Remember accessibility
Form fields can easily be read by screen readers and other accessible devices by following technical specifications and following the front end tips in this article. If the asterisk is used without proper technical implications, accessible devices will not know what it means.
Only ask what is necessary
First off, do you like your time being wasted? Neither do I. The issue is that forms tend to be longer than they need to be. We are asking for information because “it would be nice” or it is “something we could use one day”.
“Necessary” means that the information in the field is important to fulfilling the goal of the form. Any field that is required should be critical to the form’s mission. If someone is signing up for a monthly email newsletter, email address is technically required. Favorite ice cream flavor is not. It also means that the person, company or organization that is hosting the form has a real plan for what to do with that information. For example, a real plan would be that you plan to send everyone ice cream on the first day of summer.
By asking only what is necessary, it’s often likely that all fields will be technically required. This is a great spot to be in as there won’t be anything additional on your form, and this includes the beloved “(optional)” that I wrote about above.
The golden rule: Think
What this boils down to is think about the form you are creating. Do all these fields need to be there? What is required? Am I using an arbitrary symbol (*) or harsh language (“required”)? Or am I marking optional fields as such? (<– last question FTW.)
In times of yesteryear when redesigning websites for Duke University, the contact form was literally one of the last things I would think about. It typically went something like this: the week (or, err, day) before launch, I’d either add a Webform (we were using Drupal) to a client’s site or remind a dev to enable the Webform module. Most of the time, I’d create a basic form with name, email, and text box, then send it to the client with a note like, “I’ll train you on how to edit this form.” ← this is not an okay way to be! I’ve changed to a more user-centered perspective out of respect for the person filling out the form.
Long story short, let’s do our part to make more effective — and more welcoming — forms by marking optional fields as such and dropping “required” from our front-end vocabulary.
Want to hear more? Come to UX New Zealand!
If you’d like to hear what Julie has to say about designing forms, plus a bunch of other cool UX-related talks, head along to UX New Zealand 2017 hosted by Optimal Workshop. The conference runs from 11-13 October including a day of fantastic workshops, and you can get your tickets here. Got a burning question you’d like to ask Julie before the conference? You can Tweet her here: @julie_away
