Should required fields be marked?(user-interface.io)
user-interface.io
Should required fields be marked?
https://user-interface.io/should-required-fields-be-marked/
48 comments
Wouldn't it depend entirely on which is more common in your form? If it's a medical form and 95% of the fields are required, mark the optional ones. If it's a social network sign-up page and most of the fields are optional, mark the required ones. I don't know what kind of slope-browed sadist wouldn't mark anything at all.
Another UI/UX "expert" who needs to reinvent the wheel to justify his existence.
Of course it should. Who hasn't had the experience of an unhelpful message telling us that all required fields be completed, but without indicating just which those are supposed to be. The question is horseshit.
Here's a wild thought: only put required fields on your form.
Designing UIs has been part of my job for a while now, and it's always about the bigger picture. Where is this "optional" information being used? If it's optional, does this introduce complexity down the line (handling / not handling it depending on whether it was provided)?
You can always break down and simplify things. Perhaps this optional information is irrelevant -- exclude it altogether. Is it relevant in some contexts only? Handle it separately for these contexts only.
Marking "required" fields is lazy design imo.
Designing UIs has been part of my job for a while now, and it's always about the bigger picture. Where is this "optional" information being used? If it's optional, does this introduce complexity down the line (handling / not handling it depending on whether it was provided)?
You can always break down and simplify things. Perhaps this optional information is irrelevant -- exclude it altogether. Is it relevant in some contexts only? Handle it separately for these contexts only.
Marking "required" fields is lazy design imo.
I'm not sure we can always interpret 'optional' as 'nice to have but not necessary'. Optional fields can often cover edge or alternate cases like an apartment number in addition to a street address, a dietary or other accessibility accommodation, etc.
You could work around it by adding a bunch of conditional fields which then move more work onto the person filling in the form (tell me you need the extra fields then I'll show them and they will then be required) and add code complexity (more UI flows to test).
Many optional fields are indeed nice to have but assuming they all are misses that the world has a lot of fuzzy edges, and optional spaces handle those with a simple convention that many people expect and understand.
You could work around it by adding a bunch of conditional fields which then move more work onto the person filling in the form (tell me you need the extra fields then I'll show them and they will then be required) and add code complexity (more UI flows to test).
Many optional fields are indeed nice to have but assuming they all are misses that the world has a lot of fuzzy edges, and optional spaces handle those with a simple convention that many people expect and understand.
I think sometimes there can be a good use-case for it.
Consider something like a contact form for an airline — they can find your booking more quickly if they have your booking reference number to hand, so asking for it speeds up the process. That said, they can still find your booking without it, it just takes a bit longer and has a bit of a margin for error (e.g. two customers with the same name on the same flight).
If there was a "zero tolerance" of optional fields, you'd have to choose between forcing the customer to have it (which is worse service) or never asking for it (which is pushing more work to the team & increasing costs).
Consider something like a contact form for an airline — they can find your booking more quickly if they have your booking reference number to hand, so asking for it speeds up the process. That said, they can still find your booking without it, it just takes a bit longer and has a bit of a margin for error (e.g. two customers with the same name on the same flight).
If there was a "zero tolerance" of optional fields, you'd have to choose between forcing the customer to have it (which is worse service) or never asking for it (which is pushing more work to the team & increasing costs).
I think in this case we're looking at a required input with an optional lookup workflow -- if you have that extra piece of information, you can take a shortcut.
I'd approach that bit of UX by asking the user to provide one of the pieces of information required to proceed: either the name, phone number, or booking number. Depending on what they provide, the flow proceeds to the appropriate next step.
In this example I would probably structure it so that if they can only provide the name or phone number, the next thing they see is a disambiguation / confirmation dialog, which also shows the booking number. One of the fields is required, but it doesn't matter which one. In cases like this I'd like to indicate completion by enabling the previously disabled "next" / "proceed" button.
This fork in the flow can then merge back into "standard" flow of requiring the booking number to proceed -- keep the business logic / implementation simple, regardless of whether the user enters the booking no directly, or it is looked up by the system.
I'd approach that bit of UX by asking the user to provide one of the pieces of information required to proceed: either the name, phone number, or booking number. Depending on what they provide, the flow proceeds to the appropriate next step.
In this example I would probably structure it so that if they can only provide the name or phone number, the next thing they see is a disambiguation / confirmation dialog, which also shows the booking number. One of the fields is required, but it doesn't matter which one. In cases like this I'd like to indicate completion by enabling the previously disabled "next" / "proceed" button.
This fork in the flow can then merge back into "standard" flow of requiring the booking number to proceed -- keep the business logic / implementation simple, regardless of whether the user enters the booking no directly, or it is looked up by the system.
Sometimes building out a 'wizard' for these types of scenarios are worthwhile and help the user navigate — you've a choice on which info to provide but you must provide at least one (as you described).
But on shorter forms (e.g. "Add a gift message" on an online order), I think they can be overkill, both extra dev effort but also extra friction for the user.
ETA: just when you say — " I think in this case we're looking at a required input with an optional lookup workflow -- if you have that extra piece of information, you can take a shortcut."
That's another distinction too — I think this is true of the business process as a whole, but possibly not all within this form.
For some businesses, it could make sense for this to be just one more data point that's sent along in the message rather than trying to build out a completely automated form submission (e.g. if the ticket was going to be picked up manually anyway)
But on shorter forms (e.g. "Add a gift message" on an online order), I think they can be overkill, both extra dev effort but also extra friction for the user.
ETA: just when you say — " I think in this case we're looking at a required input with an optional lookup workflow -- if you have that extra piece of information, you can take a shortcut."
That's another distinction too — I think this is true of the business process as a whole, but possibly not all within this form.
For some businesses, it could make sense for this to be just one more data point that's sent along in the message rather than trying to build out a completely automated form submission (e.g. if the ticket was going to be picked up manually anyway)
The article actually proposes the same.
However, I see some issues with this:
- _Very_ common forms usually need to have optional fields - Addresses being a notable example, where almost everything is optional (example: PO boxes in Germany which don't need a street, or c/o notes)
- And because of that, any form that does not mark required fields - even if all fields are required - creates confusion about what needs to be filled in, since we are trained that forms can and will include optional fields. Nothing disrupts the flow more than validation errors, because then you need to backtrack.
- To make an implication of the previous item explicit: Just because it is obvious to _you_ that all things are required, it might not be obvious to the user.
counterpoint: the place where I usually order my pizza (without an account, nice) has an optional field for phone number and they even write "in case something goes wrong". If this was an ecommerce order then yes, I'd rather be contacted by mail. If they have a new delivery person that can't find the building, I'd prefer to be called. But making it mandatory is also bad. What if I only had internet at a building but no phone number? Am I not allowed to order pizza?
One of the classic examples of an "optional" field is "Address line 2" - many people just have 123 Main Street, but some people need place to put Apt, Suite, Care of, etc.
That's easily accommodated by providing a single, required, multi-line input.
Country, Zip/Postal Code, PO Box.
Preach! Came here to say the same thing. But you know product/stakeholders can't help themselves asking for more than they need :)
So should a phone number be required or not when ordering something? It's commonly used to text delivery times etc. Or what about a contact form where you're given the option of a call back.
Or what about if it's a government form and they're legally required to ask race, gender etc, but you aren't required to answer.
I don't disagree with the sentiment, but you very quickly run in to situations where you need optionality. It's like making apps easy to use by having no options. Great in theory but annoying in practice.
Or what about if it's a government form and they're legally required to ask race, gender etc, but you aren't required to answer.
I don't disagree with the sentiment, but you very quickly run in to situations where you need optionality. It's like making apps easy to use by having no options. Great in theory but annoying in practice.
Address Line 2.
PO Box.
Country.
Zip/Postal Code.
Middle Name.
Phone extension.
PO Box.
Country.
Zip/Postal Code.
Middle Name.
Phone extension.
>However, there is another famous UI book written in Russian. The author of this book is against marking fields as required due to the following reasons.
But which book is this?
But which book is this?
https://bureau.ru/books/ui/ this one
Web Incubator Community Group forum topic:
Browsers should clearly mark required fields
https://discourse.wicg.io/t/browsers-should-clearly-mark-req...
https://discourse.wicg.io/t/browsers-should-clearly-mark-req...
Of course they should be. The only question is how.
> Another interesting approach. The author shows an example where you have a site URL input and the label says "Your site, if you have one". Or, the label is "Site" and there is a hint below it: "if you have one".
> On the one hand, it feels more natural to me. It's like asking people in real life "Hey, may I have caramel syrup if you have one?".
Strange that a UI designer might consider more natural language in a form to be better, as it seems antithetical to "Don't make me think".
> On the one hand, it feels more natural to me. It's like asking people in real life "Hey, may I have caramel syrup if you have one?".
Strange that a UI designer might consider more natural language in a form to be better, as it seems antithetical to "Don't make me think".
Better title: “Should required fields be marked with asterisks, or something else?”
If you're interested in usability topics, https://www.nngroup.com/articles/ is a much better source.
Absolutely. Even if only for the timesaving.
A simple and clear approach is adding "(required)", or the localised equivalent, to the required fields.
> Asterisks are an invention of WEB. Operating systems usually don't use them at all.
Asterisks aren't an invention of the web, they're a hold over from paper forms. It is/was common to have an asterisk beside required fields. Because that was already a convention it was adopted by designers & ported over to digital.
> You can separate required and non required fields
I think this is good when its appropriate to the data. It's almost like you'd apply it at a fieldset level rather than field level. As in, asking for username/email/password and then in another section asking for what your interests are for the algo recommendations is great.
If you have something like fields for name — first name/last name are both mandatory; middle name is optional — it would really break the flow of the form if they weren't in conventional order.
Asterisks aren't an invention of the web, they're a hold over from paper forms. It is/was common to have an asterisk beside required fields. Because that was already a convention it was adopted by designers & ported over to digital.
> You can separate required and non required fields
I think this is good when its appropriate to the data. It's almost like you'd apply it at a fieldset level rather than field level. As in, asking for username/email/password and then in another section asking for what your interests are for the algo recommendations is great.
If you have something like fields for name — first name/last name are both mandatory; middle name is optional — it would really break the flow of the form if they weren't in conventional order.
Forms that ask for names should just as for the name and not try to force the developers cultural view of how names are constructed on the user.
Agree that _systems as a whole_ should be designed for one name, but that's often out of the hands of whoever is developing the form.
If the system _is_ designed to require a first name/last name, trying to correct for that on the front-end just makes the problem worse in my opinion (e.g. doing something like breaking on space and calling the first bit the "first name" and the second bit the "surname").
If the system _is_ designed to require a first name/last name, trying to correct for that on the front-end just makes the problem worse in my opinion (e.g. doing something like breaking on space and calling the first bit the "first name" and the second bit the "surname").
It's rather off-putting to always be referred to by your full legal name. You might need that for billing statements, but other times you might want to just address people by their first names or as "Mr./Mrs. Doe". Normal communication in our culture requires understanding the cultural use of names.
Or you could just have fields for "full name" and "preferred name".
What if I prefer Firstname in casual settings, Mr. Lastname in fancy settings, and Firstname Lastname as a fallback when the setting isn't so obvious? For people with such preferences, a schema of prefix/first/last actually does make more sense than a schema of legal/preferred.
But overall, for global optimization, I'm a fan of legal/preferred.
But overall, for global optimization, I'm a fan of legal/preferred.
Then when you enter preferred name, you put the name you would prefer.
I'm saying I prefer different things in different contexts. Like if I am a student named John Bob Doe, and I set my preferred name to John in the school info system so all the authenticated websites say "Hi, John" in the personalized user header rather than something more verbose, that doesn't mean I prefer that they use only "John" for all but the most legal of matters. I want them to use Mr. Doe when etiquette suggests same, John Doe when introducing me to an audience (say, on stage or in the news), John B. Doe on my diploma, etc. This nuance is what the prefix/first/mid/last schema inherently provides for, in cultures that utilize it. You'd need a whole suite of preferred name fields otherwise.
That said, global inclusivity does seem to be more important.
That said, global inclusivity does seem to be more important.
I suspect that you are conflating first with given and last with family. Not everyone in the world does it that way. Icelanders use patronymics not family name anyway, the Spanish use something rather more complicated, Chinese names are family first, etc.
I'm aware of those things, but I'm just saying that there's no silver bullet given cultural preferences to compose a variety of forms based on omitting/concatenating discrete parts that can't be adequately stored in a globally-reasonable schema. The best we can do is compromise on (or completely do away with) any preference for rule-based composition, and instead just echo whole names without recomposing them. It's fair, but it's a compromise.
Please tell that to the government, product managers, and everybody else who want/mandate names to follow multiple pre-conceived patterns.
I work on ERP software. Name-handling is ridiculously over-complicated. FML, preferred, chosen (distinct from preferred), prior/maiden, legal/mailing, etc.
I work on ERP software. Name-handling is ridiculously over-complicated. FML, preferred, chosen (distinct from preferred), prior/maiden, legal/mailing, etc.
That assumes that there is no law or legacy system that requires names to be collected in that way, which is not a solid assumption.
> Asterisks are an invention of WEB. Operating systems usually don't use them at all.
What kind of horseshit is this? With a 5" wikipedia search:
> In the Middle Ages, the asterisk was used to emphasize a particular part of text, often linking those parts of the text to a marginal comment.
That's practically identical to the use of asterisks on the web: pointing to a side note that says that these fields are mandatory.
Also, the examples used to demo the asterisk counter-proposals are cherry-picked to be super simple. The minute your form becomes more complicated than "email/password/phone", the counter-proposals become inferior to simply using an asterisk.
PS. Who the hell spells web as "WEB" in 2022? In fact when "WEB" was ever considered proper, outside of all-caps headings?
What kind of horseshit is this? With a 5" wikipedia search:
> In the Middle Ages, the asterisk was used to emphasize a particular part of text, often linking those parts of the text to a marginal comment.
That's practically identical to the use of asterisks on the web: pointing to a side note that says that these fields are mandatory.
Also, the examples used to demo the asterisk counter-proposals are cherry-picked to be super simple. The minute your form becomes more complicated than "email/password/phone", the counter-proposals become inferior to simply using an asterisk.
PS. Who the hell spells web as "WEB" in 2022? In fact when "WEB" was ever considered proper, outside of all-caps headings?
I believe he means "the use of asterisks to mark required fields" was invented for the web. Otherwise, you'd have to be quite young and quite sheltered to not have seen asterisks in places older than the web.
Except I've seen the same on paper forms plenty of times in the past, they point at a footnote saying "Required".
It's hardly the same thing. A footnote is used for any relevant information that doesn't belong for whatever reason in the body of the text. That it could say "Required" seems neither here nor there.
> A footnote is used for any relevant information
Yes, and the one on paper forms almost always was used for "required".
Besides, when it didn't, normally there were many of them, so they were numbered instead of an asterisk. The asterisk itself was all but reserved for "required".
Yes, and the one on paper forms almost always was used for "required".
Besides, when it didn't, normally there were many of them, so they were numbered instead of an asterisk. The asterisk itself was all but reserved for "required".
> marginal comment
> side note
I find that to be disturbingly rare on the web, i.e., asterisks with no footnote do seem to have been popularized by web forms specifically. Drupal, for example, is like this, leaving the site builder to get creative if they want to add this note somewhere.
I don't have a sampling of paper forms handy to see if they, too, suffer from this, though.
> side note
I find that to be disturbingly rare on the web, i.e., asterisks with no footnote do seem to have been popularized by web forms specifically. Drupal, for example, is like this, leaving the site builder to get creative if they want to add this note somewhere.
I don't have a sampling of paper forms handy to see if they, too, suffer from this, though.
> Who the hell spells web as "WEB" in 2022?
I am not familiar with the famous UI book written in Russian that the verbiage came from, but given that it is supposedly famous, it is doubtful that it was written in 2022. Fame tends to take a fair amount of time to acquire.
> In fact when "WEB" was ever considered proper, outside of all-caps headings?
Given that the book was said to be written in Russian, we can surmise that this is translated. Perhaps even by an automated tool. It is unlikely to be what one would choose if they were writing natively, but that isn't the case here.
As long as the intent is conveyed it is proper. There are no rules, just outcomes.
I am not familiar with the famous UI book written in Russian that the verbiage came from, but given that it is supposedly famous, it is doubtful that it was written in 2022. Fame tends to take a fair amount of time to acquire.
> In fact when "WEB" was ever considered proper, outside of all-caps headings?
Given that the book was said to be written in Russian, we can surmise that this is translated. Perhaps even by an automated tool. It is unlikely to be what one would choose if they were writing natively, but that isn't the case here.
As long as the intent is conveyed it is proper. There are no rules, just outcomes.
[deleted]
What forms could have existed in the Middle Ages that would necessitate using an asterisk for a required field???
The point is that it hardly matters whether you're putting an asterisk near a piece of text or near a form field. The usage is the same either way. The issue, IMHO, is when the asterisk isn't explained on the same page, because that's the point at which it evolves from "I have something else to say about this" to "this field is required."