There is no single proper answer but the control depends on the context.

Checkbox is suitable to minimize clutter but its use is limited for cases where described choice has also clear opposite meaning (without need of mentioning it) :

[X] include subdirectories

Radio buttons are suitable when making something more explicit or if choices need separate descriptions:

Overwrite files when copying (cannot be undone):



(•) Yes, overwrite   ( ) No

Radio buttons are also the best control to initiate with no choice made.

Dropdown menu (still with 2 choices) is suitable for choice which users should not typically change etc. Other choices are not seen and the change needs 2 clicks:

Format drive for the following file system:   exFAT32 ▼

(after opening, the other choice is NTFS).

Of course, these are not the only criteria. If you already have a prevailing cluster of similar controls, you add another one to match them. Or sometimes it is layout which rules the primary control type to use, for example some options look more gettable if they are aligned in table. And sometimes you need to add multi-line labels or icons to the choices, what implies the control to use.

So the choice is on you, the goal is make the UI streamlined, but making important choices explicit and some others stand out of user's way.

I would use the checkbox, because:

• it is visually concise (vs. radioboxes taking more screen space)


• it is the bare minimum necessary to get the job done


• it is a classic UI widget and people are familiar with it (though this applies to radio boxes too)


• a paper version of the form can look the same (though some paper surveys use radioboxes)

Radioboxes would be a better choice if you had more than 2 states. For example, in a survey you might need {yes, no, I don't know, prefer not to say} in order to differentiate between the nuances of any option other than yes.

It would help if you asked the previous generation of people who made this interface about the rationale behind the use of radioboxes. Maybe there is a good reason for that, but it has not been documented.

If you really need to cover all the use cases:

• Checkmark won't work because it can only cover two cases.


• Radio buttons should cover it, but you are missing the third option. Something in the line of "I would rather not say." Because the current setup would break if you accidentally selected something (but by the look of it you probably support unchecking the radio button?) which I don't think is a good practice.

You can read this interesting article on radio buttons by Norman Group if you need some more insight.

The checkbox is used to select or affirm a choice. The question "Do you have...?" is not offering a choice so a checkbox does not apply to the question. It even appears to select the question alone.

So a choice must be offered--yes or no. Then use the checkbox for choice selection.

For your particular case it sounds like you need to add a third "N/A" option that is selected by default.

With regard to use of checkboxes vs. yes/no radios, I think checkboxes work better for situations where fields tend to remain "as they were" when the user first entered the form.

For example:

With proper grouping by the UX designer, this allows users to quickly skip over areas of the form that are not relevant.

The radio button, in the way you show it being used, emphasizes that a choice is required, better than a checkbox that could be left blank would.

@hsan 's comment on the question is important: if you need to be sure that the user has truly intended 'No' as their answer, you need them to actively make a selection, so the form is not submittable until they have made it.

For this, a select control with an disabled first option of 'please select' works well: https://codepen.io/anon/pen/LaZzzP

<label for="mandatory-yes-no">Do you need the thing?</label>

<select id="mandatory-yes-no">

  <option disabled selected> Please select</option>

  <option> Yes </option>

  <option> No </option>

</select>

By making the default state a valid 'choice', you risk the user just overlooking or not considering it. Whether that risk is acceptable or desirable depends on the situation.

As many other answers have said, it depends on the context

I would like to add though that it depends on not just the question you're asking but also how much you want the user to think about the question and their response. A radio box requires some action to move on while a checkbox can be skimmed over.

As DenR89 says, you can never be sure if a checkbox has been answered negatively or ignored. Sometimes this is ok. Sometimes you need to be certain that the user has understood the question and provided an honest response. For example, on a car insurance application, you might use a radio box for:

Do you own the car?

( ) Yes ( ) No

As there might be legal implications for assuming this incorrectly. However, you might use a checkbox in the same form for:

[ ] Include breakdown cover

Where the default (no breakdown cover) is correct for most people and it won't affect the validity of an insurance policy if this is missed.

Very big forms

People get bored/frustrated with very big forms. For these cases, I would suggest radio buttons as it forces people to read the question and make a choice, preventing laziness from letting people skim over checkboxes.

This only really applies while we're talking about a yes/no/null radio box vs a single checkbox. If the radio box is initially in a "no" state, it is essentially the same as a checkbox. If you can replace the several questions with:

Do you have:

[ ] Thing 1

[ ] Thing 2

[ ] Thing 3

...

Then this is a completely different question.

IMHO

Radio buttons

1. 
   

   User should only be able to select one single option

   
   
   

   (o)Duck ( )Goose ( )Avenging Condor of Death

   
   



2. NO answer is not an Answer. Once you select (click on a radio button) one of the 3 options in the previous example, you can only change your selection, not unselect.

Checkboxes

1. User can select multiple options

Toppings:
[ ] Swiss Cheese
[x] Strange Cheese
[ ] Mystery Meat
[x] Soylent Green

2. NO answer is a valid answer. i.e. in the previous example you can decide you want no toppings.

Neither one is correct.

Radios and checkboxes are both designed for lists.
Therefore they would be used in a case like this where there are multiple adjective (numbers/quantities) or noun (object 1, 2, 3) options asked (at least two items).

Which of the following do you have?

- Whatever 1

- Whatever 2

- Whatever 3

The difference is that radios limit your selection to just one option while checklists allow you to select multiple options (ie. what's your favorite color? (radio) vs. what color(s) do you like? (checklist)).

What you are trying to accomplish requires neither radios nor checkboxes as it is not a list but rather a this or that statement. This instead requires buttons. This is commonly seen on software following questions like "Are you sure you want to delete this?" or "Do you want to install this software?"

Since this is a web form, chances are it's using HTML Radio Buttons. I would edit the code like this to hide the radio circles as you are only showing the options yes or no.

I will also go with the first option (yes/no radio). But here is the most important thing to understand. And that is, why to go with the first option:

You are bounding user with the choice. User's self-esteem is playing a crucial role; in sub-conscious, he is the decision maker in the first case. So "most of the people" will choose the first option only.

But in some cases, like terms and conditions, the checkbox is the better option as you don't want the user to bother clicking or not clicking. (already checked!)

I prefer the material design convention for selection controls (radios, checkboxes, switches) as it makes things immediately intuitive for the user:

• Radio buttons to select a single option from a list




• Checkboxes to select one or multiple options from a list




• Switches to toggle a binary option (on/off, yes/no)

In your case, I would go with switches.