Both our checkout usability study of 15 major e-commerce sites, our mobile e-commerce usability study of 18 leading mobile sites, and our most recent large-scale eye-tracking study of checkouts, have all confirmed the same thing: checkout processes and long sign-up forms need to mark both the required and optional fields explicitly.
On the sites that didn’t explicitly denote both field types (i.e. optional and required) the test subjects spent longer time filling out the fields and more frequently ran into entirely preventable “Field is required” validation errors. In fact, when testing mobile checkouts, 75% of the test subjects experienced severe form usability issues on sites that failed to mark both required and optional fields clearly.
The most common mistake – made by 63% of the top 100 e-commerce checkouts – is to only denote one of the types – i.e. either only denoting required fields or the optional ones (the latter has the most severe usability consequences). Another common issue was observed on checkout steps where all the fields were required (this is often the case at the ‘Payment’ step), where some sites neglect to explicitly mark any of the fields as being required – leading to unnecessary form errors and confusion.
The fix is easy: explicitly mark each and every field as optional / required (denoting both types throughout the form). Yet, when benchmarking the top 100 US checkout processes, only 9% of the sites explicitly marked both field types. In this article we’ll therefore share our research findings on why:
- It’s necessary to mark both optional and required fields (and not just one type)
- Only denoting optional fields is worse than only denoting required fields
- Forms where all fields are required still need to mark each individual field as required
- The issue is even more severe on mobile sites
We’ll end the article with a couple of “best practice” examples from sites that do denote both field types to remove any uncertainty and improve form completion times.
Note: the findings shared in this article relate to checkout forms and long account creation forms. Other forms, in particular short sign-up and contact forms, don’t seem to be affected anywhere nearly as much by the issues described and may therefore employ alternative designs.
1) Why It’s Necessary to Indicate Both Field Types
What information is optional and what’s required varies from site to site. On some sites phone is optional while other sites require it (read this if you do require phone), on other sites the credit card CVV code is needed while others rely on the cardholder name for their card verification mechanism.
So while it might seem obvious to the site designer that e.g. phone isn’t required on their site but all the other payment fields are, this will by no means be obvious to the average user. Users simply have no way to “intuitively know” a site’s requirements beforehand – they need to figure it out on a site-by-site basis for each and every form they fill out. This is why it’s necessary to indicate which fields are required and which aren’t – so users don’t have to figure it out by trial and error.
Now, an argument could still be made for only denoting one of the field types (e.g. only denoting required fields) and then have the user infer that if the three previous fields were marked as required but this current field isn’t, then that means the field is optional. Alas, having the user infer whether a field is required or optional by how the opposite field type is denoted proved troublesome during our usability tests.
The most common side effect was that the test subjects spent more time completing the form, but in some cases the predicament was more severe with the subjects feeling pressured into giving up more personal information than they were actually required to (because they thought an optional field was required) or receiving validation error messages because they left required fields blank.
The problem is rooted in a basic user behavior: users typically want to fill out as few form fields as possible, yet they are at the same time incredibly error-averse and will often go out of their way to pre-empt any form field validation errors. In short: most users want to fill out all required fields the first time around but spend minimal time on optional ones. This is at odds with forcing the user to infer the whether a field is required by what the opposite fields are marked since it makes the user spend needless time trying to deduce this.
During testing we frequently observe users having a laser-focus on the current field as they progress throughout the form – especially as they enter a new field and try to work out its context. At the end of the day, most form fields look exactly the same if you remove their labels, and most users are therefore intensely focused on decoding the field label. Forcing the user to infer whether a field is optional or not by how the opposite type of field is denoted tends to disrupt this focus and decoding process.
We often observe test subjects enter a new field, only to scroll up and down the page, looking at other fields to infer if the current field is required or not, and then as they’ve worked out the answer, scroll back to the field only to re-read its label to make sure they understood and remembered its context correctly, and finally then decide to fill out the field or skip it. Obviously this increases form completion times and taints the user’s form filling experience.
By explicitly denoting both optional and required fields the user isn’t forced to infer anything and can stay focused on just the field they are filling out and are consequently able to progress seamlessly throughout the entire form field by field without any back-and-forth scanning of previous fields.
It’s important to underscore that while only explicitly denoting one type of field can disrupt the user’s typing process, the vast majority of users are perfectly capable of correctly inferring whether a field is optional or required – it’s just not as smooth a form filling experience. However, a few times during testing we’ve also observed test subjects that were unable to correctly infer if a field was required or optional. While such instances may be low in frequency, they are high in severity, as it inevitably leads users to leave required fields blank (resulting in validation errors) and filling out optional fields they’d prefer skipping (resulting in user frustration and potentially raising privacy concerns). The latter has in some cases been the direct cause of site abandonments.
2) Why Only Denoting Optional Fields is Worse Than Only Denoting Required Fields
While we strongly recommend denoting both field types, many sites seem to insist on only displaying one type and force their users to infer the opposite field type from those. We’d therefore be remiss not to share our test findings on this design strategy (even if we don’t recommend it), because it turns out that there’s a difference in user-friendliness between only denoting optional fields vs only denoting the required fields.
In checkout processes and long account creation forms, the majority of the fields tend to be required. The user therefore often have to work their way through a great number of mandatory fields before stumbling upon an optional one.
During testing we often observe instances where the first optional field in the form is so far down the page that it’s not in test subject’s viewport. This becomes problematic because when the user starts scanning the page to infer whether their current field is required or not by finding a field that is denoted, they don’t find one. While some test subjects at this point begin scrolling the page, a great deal of the subjects assume that the site simply doesn’t denote any fields at all. These users then simply begin guessing whether fields are required, and many consequently end up leaving required fields blank because they assume the fields to be optional.
Even for the users that do begin scanning the entire form, it’s clearly a lot more work when the denoted fields are few and far apart. When denoting optional fields rather than the required ones, the user is less likely to intuitively deduce the current field’s type from the upcoming one’s simply because optional fields tend to be few and far apart.
When sites only denote the required fields, we also observe issues – although less frequently. For example, the test subjects would often overlook the lack of an asterisk if an optional field was squeezed in between a long sequence of required fields, making them believe the field was required even if it wasn’t. This can cause much dismay in users as they think they’re being forced to hand over personal information they’d rather not share.
Another more surprising but actually quite common occurrence is users who do notice the missing asterisk but still feel like they have to fill in the field – often speculating that the site simply forgot to add the asterisk. As one user explained when noticing a phone field without the asterisk: “Here I would feel like I have to fill out the phone number field because otherwise I might get in trouble in a little while.”
This is a great example of just how error-averse some users are. They simply don’t want to entertain the idea of receiving a validation error and would therefore rather err on the side of disclosing additional personal information – even if they feel uneasy doing so.
3) Mark Each Field Individually Even if the Entire Form is Required
It’s not uncommon that all fields in a given checkout step are required. The “Payment” step seems to be a particularly common case. In these instances one may be tempted to simply state at the top of the page that “All fields are required.” Alas, testing shows that this doesn’t suffice as some users inevitably end up overlooking the disclaimer.
When users fail to notice such “All fields are required” disclaimers, they often begin wondering if perhaps some of the fields are optional – even on the “Payment” page during checkout where they obviously know that some of the fields are required. This problem is largely a result of these fields being inconsistently required across the web – different sites require different types of payment details, so what may be optional on one site is required on another.
Some sites require a ‘Card Security Code’ while other sites may request a ‘Cardholder Name’, with some sites requiring both to complete the transaction. When it varies like this across the web, users understandably cannot predict what any particular site requires, and it therefore has to be made explicit what is and isn’t required – even if that means denoting each and every field individually as required. Better to be repetitive but clear than concise but opaque.
Doubt over field requirement in particular occurs when the information asked for is seemingly unnecessary (in the eyes of the user). On an address form this may be fields for phone, title, and email, while in a credit card form it could be the billing zip code (for credit card), card security code (CVV), issuing bank, and cardholder name.
Therefore, even if a single All fields are required” disclaimer at the top of the page may on the surface seem like a more elegant solution, some users will unfortunately overlook this (making it a case of false simplicity). Hence it’s recommended to denote each field individually even if all of them are required to ensure absolute clarity. Repetition isn’t redundant if it improves clarity.
Note: It bears repeating that these test findings, and hence recommendations, apply to checkout processes and long account creation forms. A 3-field sign-up form may certainly suffice without individually denoting all fields as required.
4) Why the Issue is Even More Severe on Mobile Sites
“I have no idea which fields I should fill, and what I should fill in these business phone fields, because I don’t have a business phone,” a subject complained, “I’m completely blank.”
When the test subjects reached the checkout flow during our mobile e-commerce study, 75% of them experienced severe form usability issues on the mobile sites that failed to clearly denote required or optional fields, or did so inconsistently. In a few instances, the subjects even abandoned their purchase because they perceived an optional field to be required, thinking the site demanded data of them which they did not have (such as a ‘business phone’).
On a mobile device, deducing if the current field is optional or required based on what other fields are marked as is even more taxing than on a desktop computer, as there’s only a few form fields visible at any given time in the user’s viewport (with the touch keyboard open, the user may only be able to see 2-3 fields).
Users will therefore often have to scroll until they notice a marked field (potentially leaving the current field out of view), deduce its meaning, memorize it, then relocate the current field (which the subjects were often observed to scroll past on their way back), and then lastly apply the reverse logic to the current field (“if that other field said “optional” and this field doesn’t say anything, then it must be because it’s required”). Clearly this doesn’t make for a smooth and seamless form filling experience.
Because of the reduced page context on mobile, the user is less likely to intuitively deduce whether a field is required from the surrounding fields, simply because fewer of the surrounding fields will be visible at any given time. We also frequently observe how test subjects have a shorter memory span on mobile due to this decrease in page context, making them more quickly forget things like previously denoted fields (or at least making them sufficiently unsure so they scroll back up to verify).
During testing, many subjects ended up simply guessing, which of course resulted in uncomfort due to over-disclosure of personal information (when they thought an optional field was required) and needless form errors (when they thought a required field was optional). While form errors are always a poor experience, they tend to be particularly painful on mobile because it’s often more difficult to locate and correct form field errors due to the smaller screen and touch controls.
It’s therefore particularly important to denote both required and optional fields on mobile sites, as the decrease in page context (caused by the smaller screen) makes deducing a field’s type even more challenging for the user.
How to Place and Style the * and “Optional” Labels
Follow the web convention, which is to write ‘Optional’ next to optional fields, and use an * (asterisk) or spell out ‘Required’ next to mandatory fields.
Most users are really impatient online and just want to know what they have to do in order to complete the order and get their products. This often leads to an intense focus on the current field as touched upon earlier. By marking up each field the user doesn’t have to worry about any other fields than the one they are currently filling out.
This allows the user to seamlessly progress field-by-field throughout the form, lowering form completion times and eliminating uncertainty about whether a particular field is required or not, which in turn lowers form validation errors and uncomfort produced by (unnecessary) over-disclosure of personal information.
And it doesn’t even require development resources – it’s basically a matter of adding one word (‘optional’ or ‘required’ / * ) next to each field in the checkout process or account creation form. That’s what we call low-hanging fruit.