In many cases, when creating an A/B choice for a user, there is a clear option that should be the default; if not, the debates can rage... and if the choices are not clearly boolean (Yes or No), it gets sticky.

I am working on an app in which the user can create a new "case" (database record) on the fly. When they create a new case, they are presented with a form, with many of the fields optional. Some of those optional fields are obvious boolean choices, such as "Yes/No"; others are less clear, such as "Delivery/Retrieval," "Imperial/Metric" and "Male/Female."

The first question is this: for fields that have an A/B exclusive option, a toggle seems to be an appropriate control to use (especially when one hates radio buttons). But if the fields are OPTIONAL and should not contain a value, how do you represent them by default when the form first appears?

There is no obvious default choice for Male/Female, and if the user does not select one at all, we don't want to throw a default into the data record. We could not enter the value into the record until they edit it, but if they look at a control and see a value that looks correct by default, they may not touch it, and in that situation it would therefore not be entered into the record at all, though it LOOKS selected.

Is there any best practice around defaulting this sort of non-boolean a/b choice? Anyone?

The second question is this: what is the best way to represent non-boolean values on a toggle switch? I have three possible options I'm playing with now:

Text on the switch and the background

Text on the switch that changes Text not on switch at all And sucking it up and doing it radio-style

There appear to be benefits and drawbacks to each - any thoughts around this from the community at large?

4 Answers 4


Well, after much deliberation, we've come up with a solution that I have not seen before, but seems as if it will solve our problem (and we'll see tomorrow if some user tests bear this out).

Stylistically, we decided to go with our third option above, the normal, iOS-style toggle with the labels on each side. However, to deal with the "optional" factor - and the fact that we don't want those optional fields entered into the database unless the user deliberately makes a selection, we've created a third state:

enter image description here

The toggle shows up, but rather than being active, it exists in a null state, with neither option selected, and the thumb sitting squarely in the middle, in the color we are using throughout to indicate a significant action.

If the user does nothing, those toggles remain in the null state. If, however, a user wants to set that value, the orange action color and grayed out options indicates to the user that they need to touch to activate the control.

Once they do, the "null toggle" (which is just a button overlaid on a real toggle, for which we have determined a default value) disappears, the default value of the real toggle is reveled, and that value is entered into the data record:

enter image description here

If they like the default value, they need do nothing more and their selection is recorded. If they touch it again to toggle, the value switches and the new value is recorded.

Clearly there is a certain amount of learning required. But this is a closed audience for a very specific and functional app, and once they have interacted with this control once, I expect that they will easily understand it everywhere else they encounter it.

I'd love to hear people's thoughts, and I'll reply with some results from our tests.

  • As a follow-up, this format worked very well; one user was unsure why both things were grayed out, but he then proceeded correctly without any instruction, and on the whole users were able to work through the forms correctly without any trouble. Actual mileage may vary ;-)
    – Mattynabib
    Commented Aug 15, 2016 at 13:50
  • 1
    Thank you! Well done. I hope others can learn from your excellent work. I know I have. Kind regards.
    – patricia_c
    Commented Oct 12, 2016 at 15:20
  • I like the concept and think it's great that you're trying something new instead of "simply" copying existing standards. I do worry that people might perceive the grey text as unavailable or disabled.
    – Tom.K
    Commented Oct 13, 2016 at 12:44

I'm not sure if this will answer your question perfectly as this might not be the best practise in the design community but as a user I noticed apple does it with multiple toggle buttons to keep it straight forward to toggle the entry to select the value have another toggle switch here Now for the second question it’s upto the style you prefer for your app but the first option looks more comfortable to me [Only my opinion!]. But if the options are not obvious like male/female or send/receive I think the second option where you show both the options will be helpful.


The first part is about how to represent a default state on an optional toggle control, and I would suggest that the best way to avoid confusion is not to show it at all, but create a control that activates the option. For example, it can just be a button to trigger the toggle switch to appear. However, if you are providing a default value then this is not a valid option. I think it is about providing appropriate messaging and labeling that will avoid ambiguity. If you use too many combinations of colours and styles then it just becomes more confusing for the user. Unfortunately I don't think there is a standard convention, or if there is then it varies depending on the context of the user and the application.

The second part is about displaying or representing the state of the toggle buttons, and there have been similar discussions in the areas of toggle buttons and indicating the state of buttons. The short answer is that you need to make sure that wherever the labeling occurs it is clear and not ambiguous whether it is indicating the state (current or future) or the action that the user is going to perform. The best way is to actually play around with the labels and test it out with actual users because the context could vary the approach you should choose considerably. With the options you have shown, I think you don't necessarily need to grey out the non-selected option, as it seems to suggest a disabled state. The only element you need to differentiate is whether the option is selected or not, so I think the style on the DELIVERY and RETRIEVAL should be the same.


Im curious how the testing went. I found this post because we have the exact same situation where we want to show both selections and it can't be framed as a yes/no or on/off selection. We can have a default selection though (unlike make/female). So our case is a little different because it doesn't need a neutral setting. I researched other UI Dev Guidelines and I don't see a standard.... yet.

We went with version 4 of your example because it matched our product branding. Version 1 and 3 were what we discussed on a white board and were well recieved. I really like the solution you chose with the null state. I would advise that the 3 dot locations be placed about 45 pixels apart because I notice on my iPhone the tap doesn't always register when the on/off selections are close and its fat-fingered.

  • For better or for worse, before I was able to run tests on the actual app or even my prototypes of this piece, I left the company (pro tip: it was for the better). But my one regret was not being able to test some of those features more in depth. The initial reactions from people inside the company for which I was designing it, however, were very positive - it solved some database issues they'd been puzzling over around the "neutral" optional state, and made things very clear to users.
    – Mattynabib
    Commented Oct 12, 2016 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.