4 ms·

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

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

btbuildem 4y ago
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.
- another-dave 4y ago
  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)

btbuildem 4y ago

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.

another-dave 4y ago
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)