E-Commerce Checkouts Need to Mark Both Required and Optional Fields Explicitly (Only 9% Do So)

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.

Which fields are required and which are optional? Is ‘Apt. or Suite #’ required? How about ‘Contact Phone’? Some sites require a phone number while other sites don’t – alas, the user has no way of knowing without proper indicators for required and optional fields.

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:

  1. It’s necessary to mark both optional and required fields (and not just one type)
  2. Only denoting optional fields is worse than only denoting required fields
  3. Forms where all fields are required still need to mark each individual field as required
  4. 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 optional, 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.

Nordstrom doesn’t denote which fields are and aren’t required, except for a couple of general disclaimers for the first and last section in the form. During testing nearly all subjects unfortunately overlooked such general disclaimers and many therefore ran into form issues when checkout out at Nordstorm.

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.

When the field type is included as part of an inline label the context disappears as the user progresses throughout the form – making it even more taxing for the user to figure out whether their current field is required or not. Here a test subject had reached the ‘Phone number’ field, thinking it might be optional – alas, the ‘Address line 2 (optional)’ was filled out, causing the only optional-denotation in the form disappear, making it even more difficult for the user to deduce whether the phone field was required or not.

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.

Many of the test subjects ran into form validation errors as they left required fields blank – thinking (and perhaps hoping) that fields without an explicit required / optional indicator would be optional.

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.

Home Depot has a single generic disclaimer at the top of the page stating “All fields required unless noted” – unfortunately, many of the test subjects overlooked these types of disclaimers and would begin speculating whether some of the fields were optional. Obvious candidates on this page would be ‘Name on Card’, ‘Card Security ID’, and ‘Email Address’, which could all reasonably be optional as it is far from all e-commerce sites that require these details.

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’).

All the fields at this step are required but none of them are denoted as such. Fandango simply expects their users to know or deduce this themselves. However, 75% of the subjects testing this payment step stopped and speculated whether the “Billing Zip Code” field might optional.

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.

“When a field isn’t marked with anything is it then required or optional?” a subject asked at Walmart. To deduce this the user would have to scroll up several fields and see if any fields were marked ‘Optional’.

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.

United Airlines’ mobile site deviated from the web convention of using an asterisk to indicate a required field and instead used it for optional fields. This ultimately led to abandonment as test subjects like this one thought a ‘Redress Number’ (which they did not have) was required of them.

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.

This article presents the research findings from just 1 of the 642 UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.

Post a comment or Share:

User experience research, delivered twice a month

Join 18,000+ readers and get Baymard’s research articles by RSS feed or e-mail:

Due to spam, you need JavaScript to do that.

(1-click unsubscribe at any time)

Related Articles

See all 49 ‘Cart & Checkout’ articles

More E-Commerce Research

Free Research Content:

Products & Services:

Comments (29 so far)

Jessica Enders December 15, 2014

Very interesting — and controversial! — as the vast majority of sites seem to mark one and not the other. But I, for one, will be willing to move away from this de facto standard, provided there’s sufficient evidence for doing so.

I’ve been watching folks fill out long and complex forms for years, and 99% of the time they just fill out everything UNLESS they are uncomfortable or unable to provide a piece of info (what I’ll call “challenging questions”). You’re absolutely right that error aversion is very strong (and well learned, unfortunately).

Would you say the majority of the difficulties you observed arose around such “challenging” questions, rather than form content generally.

I ask because while I agree that clarity is paramount, we’re going to be adding considerable visual and cognitive noise having an indicator on every field. On mobile we’ll also have problems of space.

Is it possible the best solution is to a) eliminate unnecessary challenging questions and b) mark the remaining challenging questions as optional/explain why the info is needed (to assuage privacy concerns)?

Finally, with how many people did you test the 9 sites which mark both, and did any of them react negatively to this approach?

With thanks in anticipation,

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 15, 2014

Hi Jessica,

Thanks for your comment and questions.

The key insight here is that if you don’t mark both required and optional fields, the user can’t focus on just the field they are currently filling out – they need to take the surrounding context into account. Depending on how it is done (i.e. only denoting optional fields vs only marking required ones) and the context in which it occurs (e.g. desktop vs mobile), this introduce a light-to-heavy mental tax on the user – a tax which can be avoided simply by adding a single-word ‘Optional’ / ‘Required’ tag alongside each field’s label.

Of course from a user POV it is generally preferred to have as few questions as possible asked, so yes, if some fields are deemed unnecessary, do remove them. But this is obviously a business consideration too – maybe certain customer info has great value for customer service or for marketing. Similarly, there may be certain info some customers will happy give if they are simply assured of proper usage. Phone is a great example where if you can promise it will only be used in case of delivery issues, then some users will happily give it up – yet the field should obviously remain optional. So the best solution is to remove unnecessary form fields and then add proper explanations for the few optional fields that are deemed sufficiently valuable to be included.

We’ve conducted in-lab tests of checkouts with 63 participants (in separate think-aloud and eye-tracking studies) across roughly 20 sites. Some of them are among the 9 sites which mark both, but not all of them (note: those nine sites are from our benchmark study).

Due to spam, you need JavaScript to do that.

Jessica Enders December 16, 2014

Hi Jamie

I am questioning whether that is in fact the key insight from the research, or whether the key insight is that challenging questions need to be marked. Totally agree with you that users are wanting to know, /at the field/ whether it is required. But my hypothesis is that they only want to know for challenging questions, not all questions in general. If that’s the case, then we can reduce visual and cognitive noise, while still having a seamless experience, if on the challenging questions we either mark “optional” or explain why information needed.

I agree completely with your second para.

Thanks for the clarification around numbers. How many sessions did you run where both were marked? And in how many of those sessions did the participant react negatively to both being marked?

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 16, 2014

Hi Jessica,

Thanks for following up, we really appreciate thoughtful dialogue – it adds immensely to the articles :)

I’m not entirely sure I understand the definition of “challenging questions”? I should point out that, as we note throughout the article, these insights are related specifically to checkouts and long account creation forms. We haven’t tested surveys etc so I can’t say if the findings hold true in that context.

However, only denoting some fields (i.e. ‘challenging questions’) with a ‘required’ label but not other fields (even though they are required too), would make for a fairly inconsistent denotation of the fields and I would therefore think this would confuse users, but we haven’t tested the approach so I obviously can’t say for sure.

I find that the visual noise introduced by adding a single-word ‘Required’ tag next to the field label is rather minimal considering the overall checkout / account creation context, so the clarity gained by doing so seems to far outweigh the downside in my analysis. (Again, other form types such as surveys may very well benefit from different denotations – we haven’t tested that so we really can’t say what works best in e.g. a survey form.)

Due to spam, you need JavaScript to do that.

Jessica Enders December 21, 2014

Hi Jamie

I also really appreciate the dialogue!

When I say “challenging questions”, I mean questions that people are uncomfortable or unable to answer. I think we can usually identify these, especially if the form is tested before go live.

I also don’t recommend being inconsistent with labelling. Rather, I recommend:

- having an instruction at the top of each screen saying "all questions must be answered unless marked “(optional)”
- marking only optional questions
- eliminating as many challenging questions as possible
- making, as much as you can, the remaining challenging questions optional
- adding reassuring/explanatory text to challenging question that are required.

This achieves lowest visual and cognitive noise (remember every extra visual element has to be processed by the brain, even if not consciously) while still communicating which questions are optional and which are required. It does, however, rely on my — not yet formally tested — hypothesis that people only look to see if the question is required if it is challenging. Certainly my anecdotal evidence from testing supports it – would yours?

I do get what you’re saying about not necessarily being more widely applicable than the sorts of forms you were testing. I must confess I initially misread “and long sign-up forms” as just “long forms”, and it’s that situation where I think the visual noise of marking both really becomes oppressive. Leads me to another hypothesis, though, which is that checkout and long sign-up forms may be cases where people are particularly reluctant to give more information than needed, and thus more proactive about knowing what’s required and what’s not. Mostly I test long, complex administrative forms, not checkout/sign-up forms, so that could be a reason why we may be seeing different things.


Due to spam, you need JavaScript to do that.

Chris Poteet December 15, 2014

I normally agree with 98% of what you guys have to say. I would say that I do disagree that marking both is unnecessary. I have seen that simply marking optional fields has not proven troublesome. I would need more than anecdotal data for a conclusion that both need to be marked.

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 15, 2014

Appreciate your comment Chris.

It’s absolutely true that only marking one type won’t cause trouble for all users – indeed, as mentioned in the article, most users are perfectly capable of deducing which fields are required and optional from the one denoted type. Alas, there’s a difference between being able to do something and having a smooth, seamless experience when doing it. Our study finds that it taints the experience of at least some users. In our studies it happened to be quite a lot but obviously your mileage may vary.

Thanks for sharing.

Due to spam, you need JavaScript to do that.

Stomme poes December 15, 2014

Steve Krug said: don’t make me think. Guessing which system a website has chosen is thinking. We no like thinking. Thinking bad. I’m sure some graphic designers have complained about clear labels and straightforward instructions and text being too large. But they are not the customer, and they are not the ones being asked to think.

Telephone numbers are a big one, especially among people who cannot use them due to things like physical disability. You’re already getting our email address, why do you insist on calling us on the telephone?
This woman for example (link is to a forum post) http://community.sitepoint.com/t/disability-isnt-binary/42706/3

Due to spam, you need JavaScript to do that.

Mark R. December 15, 2014

I think Luke W, would disagree!

Due to spam, you need JavaScript to do that.

maadonna December 16, 2014

Could I please clarify something in the testing structure.

Did you compare three types of approaches:
- mandatory marked
- optional marked
- both marked

and notice that when both are marked speed and accuracy was better.

Or did you test sites that had mandatory marked and optional marked and conclude that both would be better?

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute December 16, 2014

Yes, all three design approaches were tested.

Due to spam, you need JavaScript to do that.

Trav December 16, 2014

I think the entire premise is wrong. If you want a good UX, then don’t have optional fields. Limit the form to only things required to complete the requested result. Complete the purchase transaction with the least possible cognitive load. Don’t do market research in that moment.

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 16, 2014

We certainly agree that it’s desirable to avoid asking for unnecessary information (although there may be business considerations to take into account as well – but from a pure UX perspective, we fully agree). However, even from a UX standpoint, there are some cases where certain information may be appropriate to ask for without making it required. Phone is a great example, which you can ask for “in case of delivery issues / questions” yet obviously without requiring users to provide it. (Or perhaps even better, the user might be able to sign up for a text message service with shipping updates; again, something that should be entirely optional, yet certainly isn’t an irrelevant choice to present to the user.)

Due to spam, you need JavaScript to do that.

Trav December 17, 2014

Thanks Jamie,

I appreciate that you didn’t ignore my somewhat negative comment, and I offer the following respectfully. Here’s the point I think is being missed:

As UX designers, it’s our job to convince ‘business’ that we know better than they do in this sphere.

Designing experiences that meet business goals but don’t create a sense of joy, of pleasure, of comfort in users should not be the concern of User Experience designers; perhaps the concern of ‘Business Objective’ designers, but since that’s not what I do, can’t really say.

You cite the ‘Phone’ field as a good example of something (not required that could still be important, if I’m reading between the lines) which argues for the clear exposition of the importance of each field.

I would argue a different way.

Imagine I’m the user; I’m attempting to order something from your company via your site. The simple fact that I’ve chosen to engage your site, and spend money, should tell you something about how confident I am that you’ll meet or exceed my needs. Do you believe my confidence increases when you essentially ask the question “Hey, just in case something goes wrong here, do you OPTIONALLY want to give me your phone number?”. I don’t. I believe that, as a business, you should either know for a fact that nothing will go wrong (unlikely), or specifically acknowledge that things occasionally go wrong.

As such, it’s not an optional field. It’s a field that says, “We’re both adults here, we know how the world works. Make sure we have a way to contact you immediately should the need arise. The last thing we’d want is to not meet your expectations for clear, timely communication.”

And you know what? Some things don’t require a call. Some things can be handled by email. Our job as UX Designers is to make those distinctions, and lobby for the user.

I appreciate the apparent intent of this article, but I think as UX-ers, we really need to stop this ‘Business reasons…’ argument from propagating further. If ‘Business reasons’ were what motivated the user, we wouldn’t be needed at all.


Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 17, 2014

Your comments are much appreciated, Trav, and thanks for countering – I’ll try to elaborate my view on these topics a bit below :)

I think we fundamentally agree that unnecessary fields should be removed, and it is certainly the UX designer’s job to lobby heavily for this. On this we agree.

Now, in the ideal UX world, that would mean no unnecessary fields ever existed in a web form. In practice, however, the UX designer doesn’t always get the final word and business needs are often part of the design decision. What we’re interested in exploring here is how we can create the best user experience in that environment – a context which takes business considerations into account. “Designing experiences that meet business goals” and creates (at the very least) “comfort in users”. UX designers shouldn’t isolate themselves from other disciplines and departments of the business (incl. the business-side of things), they should work together with them – obviously arguing the best case they can for great UX, and then – once all deliberations have been done and the decisions have been made – go ahead and create the best possible solution under whatever constraints there might be.

Re: Phone field. I think we’ll have to agree to disagree. As you say, sometimes you can simply do with an e-mail. Yet as you also argue, obviously a phone will be useful for urgent matters. Both are valid arguments – so should you remove the field completely or force users to submit the information? I’d argue that there are some cases (not all, but certainly some) where asking for the information but not requiring users to submit it is valid. E.g. perhaps some users would like order updates sent by text message rather than e-mail.

I think our disagreement is one of degree. Obviously, there should be legitimate reasons for including any field, otherwise they should absolutely be removed rather than made optional. We complete agree on this. I don’t, however, find that it is a completely black-and-white “necessary/unnecessary” matter – I think there exists a gray area in-between those two ends, which is where optional fields enter the equation.

Again, we much appreciate your comments Trav, we love it when our readers engage and ask tough questions – so thanks again :)

Due to spam, you need JavaScript to do that.

Trav December 17, 2014

Likewise, I appreciate your nuanced discussion, and you are completely correct: it’s not a binary situation.

I sometimes like being dogmatic and binary about an issue because it can be a useful lens to evaluate where the nuance really lies.

In the phone example, it could be argued that the initial form only include the required items; then, on the confirmation page, surface some clearly marked optional fields, where we could pose the question of text vs. phone etc. for further communication.

But this is all hypothetical, and as you point out, real-world constraints are a fundamental fact. I’m certainly no stranger to ‘Business decisions’ that require a deft UX handling! I guess my point is simply that we should push back on such things at least as hard as we strive for designing to meet them. A two-pronged attack, if you will : )

Thanks again for the discussion, and the article.

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 17, 2014

Completely agree Trav, we definitely need to stand up for our users! :)

I’m also completely with you on the idea of postponing the phone vs text preference to the receipt page – we’re big advocates of delaying discretionary options (account creation, phone vs text preferences, etc) until after the purchase has been successfully completed: http://baymard.com/blog/order-confirmation-page

Due to spam, you need JavaScript to do that.

Jessica Enders December 21, 2014

Hi Jamie and Trav

I agree with a lot of what both of you are saying, and would add that you need to cater for an additional situation: if the user has X, then they have to provide it to the business, but it’s valid for the user not to have X.

Phone (and email) is a great example of this. If the customer has a phone number, the business may need it so they can contact them if the email bounces etc. But both the business and the customer may not want the customer to be excluded just because they don’t have a phone number.

In this case, phone number should stay in the form, there should be a tip explaining how it will be used, and the field should be optional.


Due to spam, you need JavaScript to do that.

John Newman December 16, 2014

Do as I say, not as I do? http://cl.ly/image/441l3F0b2D20

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute December 16, 2014

Throughout the article we clearly state that these research findings are for checkout processes and long account creation forms. Indeed, this is even stated in the article title.

We have not tested things like comment forms, surveys, etc. and the findings will therefore not necessarily translate to those contexts. We have therefore decided to only mark the optional field in our 3-field comment form, but if you look at our checkout process you will find that we do indicate both required and optional fields :)

Due to spam, you need JavaScript to do that.

David Mannheim December 30, 2014

Thanks as usual. I think this isn’t as black and white as is made out within the article. Let me explain why. Taking the salient insight here of “both optional and required form fields should be indicated” the recommendation is to, simply put, “add one word (‘optional’ or ‘required’) next to each field”.

Did you find any issue or trouble with this? For example, some assumptions I would make on user behaviour here is that users would scan this label as:

a) it’s almost like a disclaimer such as that at the top of your Target example which users dismissed
b) it’s another word that users have to read and as Steve Krug says – get rid of half the text on your page then get rid of half again
c) when users scan the page, which they will as indicated, this is not just an additional word, but a 3 syllable additional word that could be quite hard to interpret
d) maybe this is just a design element in the example you gave – but because optional isn’t a stand out element from required or visa-versa, they look exactly the same and therefore non-differentiating.

Contextually, I think there are still issues. I’m not debating the point at all, just the implemented or recommended solution. Adversely, then again, if you were to place “optional” and an “*” you are almost comparing apples and pears to a word mixed with a symbol that users have to associate to an action.

As Jessica says – it’s controversial.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute January 2, 2015

Hi David, thank you for the comment.

Great, point. But no we did not observe any of those issues to anywhere nearly the same degree as the issue of not marking both field types explicitly. Some answers:

a) there’s a big difference between a universal page disclaimer at the top of the page and one on a field level. By having it for each field users are allowed to focus on one field at a time (as they fill it), with a single universal disclaimer they have to read the page like a book (which they of course don’t).
b) agree that general page descriptions should be concise and to the point, something that we found in our checkout studies as well. But removing the information entirely don’t make the checkout any simpler to complete for the user. Following that logic we could also remove the field labels entirely :) http://baymard.com/blog/false-simplicity
c) agree that the user’s initial scan of the checkout step might be worse off when both field types are required, but again during all three different large-scale checkout studies, the sites which marked both, proved to provide the user a much more clear form filling experience (allowing them to focus on each field individually).
d) agree that this might apply when users were scanning the checkout step as a whole, but we did not observe it as they were filling each field individually.

Due to spam, you need JavaScript to do that.

Damir January 13, 2015

This is highly controversial, and should not be taken for granted. There are other voices too: http://uxmovement.com/forms/why-users-fill-out-less-if-you-mark-required-fields/

It highly depends on users the website is targeting, some are very web savvy, others might not be. I think everyone should use some approach as a starting point, and test alternatives.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute May 15, 2015

Hi Damir, thanks for pointing to the Voluntary Over Disclosure study. The post at UXmovement rely on a good research study by Preibusch et. al. on “voluntary over disclosure effect in some web forms”. The only issue with the UXmovement article is that it assumes the findings in Preibusch’s study apply for all types of online forms.

I’ve read Preibusch research study (available at http://preibusch.de/publications/Preibusch-Krol-Beresford__voluntary_over-disclosure.pdf ) and I’m sure most reading this study will agree that it’s clear that the form tested is not a checkout form (see page 7 in the study). Thus:

  1. In Preibusch study users are unlikely to be anxious of getting form errors due to the open-style inputs tested (whereas checkout forms have data that require inputs following strict inputs).
  2. In Preibusch’s study “we did not perform any input validation” thus there were no possibility for a subsequent error experience (e.g. for those users not filling a required field) – and the negative impact such error experiences may have on conversions in a real life checkout process is a factor not included.
  3. In Preibusch’s study users aren’t in a purchase context, and therefor unlike to anxious about sending an order with invalid data, etc.
  4. In Preibusch’s study users are not asked to submit highly personal data such as phone number, email or credit card info as they are in a real checkout form. This is info users are reluctant to hand out (making required vs. optional very important). See: http://baymard.com/blog/checkout-experience-seemingly-unnecessary-information
  5. In Preibusch’s study neither the required or the optional fields are marked on a field by field basis – whereas most checkouts mark one of them on a field by field basis. Instead there’s a generic description at the top of all the form fields reading “Field 5 & 6 are mandatory. All other fields are optional”
  6. In Preibusch’s study a synthetic form were tested, i.e. there’s no surrounding graphics and elements to distract and dilute field attention.

This is not a critique of Preibusch’s study (or of you for bringing this up) – but a note of caution about the article at UXMovement which imply the findings are applicable to online checkout forms, without mentioning the constraints of the underlying study. The Preibusch study can teach us a lot about other types of web forms – it’s just not directly applicable to checkout forms.

Due to spam, you need JavaScript to do that.

Sergey Vorozhtsov May 8, 2015

We implemented “E-Commerce Checkout Usability” guide for all our stores and saw doubling of checkout conversion rates. We will soon work on implementation of other usability guidelines. Thank you Christian and Jamie for your excellent work!

Due to spam, you need JavaScript to do that.

Jason Day May 14, 2015

I agree with many of the others on here, that indicating both optional & required is a lot of visual noise for the user. In addition to error states, and contextual help, the user may not be able to see the forest for the trees.

I think the most important data point was missing from your study; what effect does required, optional, and required & optional, have on form conversion?

Due to spam, you need JavaScript to do that.

Rob Turner March 21, 2018

Obviously late to the party but I didn’t see any reference to ADA compliance which would seem to limit the presentation options.

Due to spam, you need JavaScript to do that.

Michael Crenshaw July 13, 2018

Were the variations each tested on the same forms, or were the results inferred from tests using forms that just so happened to use the various strategies?

If the latter, I’d suggest that forms using the “mark each input” strategy might be generally better-designed, skewing the test results.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute July 20, 2018

We tested and subsequently re-tested these different design combinations in very high volumes across more than 30 checkout forms. Also on sites that have “perfect” form field design (perfect styling, labels, visual clutter) – apart from missing the denotation of both required and optional form fields.

These original test findings were once again confirmed in our latest large-scale checkout testing – those latest findings are available in Baymard Premium. We might at some point do a free followup article showing the re-verified findings given the high interest and the seeming general “controversy” this topic is apparently causing.

Due to spam, you need JavaScript to do that.

Post a comment!

Due to spam, you need JavaScript to do that.