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.

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

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.

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)

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.

Address Line 2.

PO Box.

Country.

Zip/Postal Code.

Middle Name.

Phone extension.