Question

Consider the following example in a CRUD application. A user can select their favourite food from a dropdown list ("Burgers", "Pies", "Chips"). This is an optional field i.e. not mandatory. Thus a user can leave it unselected, or also update their data to unselect any choice.

Since the field is optional there are a number of scenarios:

  1. User never selects an option (null)
  2. User selects an option from the list
  3. User deselects an option and thus stores null (or some other value)

Here are some ways to design this: 1. Add a entry like "no-selection" and make the field mandatory 2. Add a guard boolean field like HasFavouriteFood that enables/disables the dropdown.

Option 1 has the advantage over 2 that it is simpler since you wont have to check the state of another field and modify the UI accordingly. However it feels untidy (since one of the values wasnt originally specified).

How would you design this?

Was it helpful?

Solution

Keeping all of the elements in the dropdown feels like the right approach. You mention that having an extra dropdown option feels untidy but I guarantee having an extra checkbox the user has to click is going to feel much more untidy.

Advantages to putting everything in the dropdown is that you can address a few different cases:

  • Does the user have a preference?
  • Does the user prefer not to answer?

Therefore your dropdown list might look like:

  • No preference
  • Prefer not to answer
  • [------]
  • Burgers
  • Pies
  • Chips

I would leave the default selection on the dropdown blank. That gives the user some incentive to click and see what the options are instead of just thinking to themselves "no preference seems fine".

It's up to you whether it makes sense to make the field required or not. If the user leaves the field blank does that imply they don't have a preference, they prefer not to answer, or did they just overlook the field?

Licensed under: CC-BY-SA with attribution
scroll top