Here are some notes about radio button and checkbox defaults for times when you need an affirmative answer.
The Nielsen/Norman Group (no relation) has an interesting article on radio buttons by Kara Pernice. Its advice is sound, but I want to note a case where there could perhaps be even more obviousness.
The next time you design a radio button interface, I'd like to advise you to think about an additional choice, which is essentially a default choice representing that a choice is not made.
Radio buttons provide for a mutually-exclusive choice. For instance, an airline serves two meals to first-class customers, one with pasta, one with rice. You can only pick one.
But this hides the implied third choice, which is not to have any meal. Better:
This may become important for legal requests for a formal, affirmative choice. For example, a health survey might ask:
But this doesn't allow the choice to say neither No nor Yes. Also, suppose you are a healthcare company that asks this question, and you don't want to be blamed if the user gets the wrong treatment according to this answer. The user might say: I was in a rush and took all of the default answers; the form reported this answer as "No," but it was actually "Yes."
Some people try to solve this with a form where neither choice is indicated by default, and the user is forced to choose one or the other:
I don't like this one, because the form typically can't be submitted with no choice, or there is no way undo choosing one of the options (there's no way to go back to the "neither is picked" scenario).
So this is missing the third option, which in some forms is "prefer not to say," or "not reported." Those two phrasings of the answer are in fact a little pushy. Does the user actually prefer not to say, or are they compelled not to say? Additionally, "not reported" is not quite right, because the user is reporting something: The user is reporting neither No or Yes. And this third option should be the default:
Now if a user accidentally takes the default answer, the healthcare company is protected because they can show that no choice was made. If a procedure must be conducted that depends on pregnancy status, they can ask again in a different setting. Additionally, the confidence in the No or Yes answer is enhanced, because the user has to make an affirmative decision to choose something other than "No choice made."
One last thing: If you implement this, make sure that the date/time of the choice is captured in the database. (It can also help to put the statement itself into the database.) People go in and out of the state of pregnancy, and you should capture that so that it's clear that the answer wasn't provided for all time. Indeed, with this in mind, the question "are you pregnant?" might be changed to:
By this means the wording for the user and the data captured on the back-end is aligned.
There's a similar problem with consents.
Let's say that you're a healthcare company and want to satisfy HIPAA requirements and encrypt personal data when in transit. In most cases, email is encrypted end-to-end with TLS, but you know of cases where this is not feasible (because the patient's email server can't handle it). Therefore, you want to ask the user for consent to send unencrypted email. With this consent, you may go ahead and send unencrypted email. Without this consent, you continue not sending such email. Thus, not sending the email is the default, whether or not you capture a consent decision. No one says "please do not send me unencrypted email" up front.
Here's another example: The request to consent to treatment. Without such consent, you won't be treated.
What this means is that it is not appropriate to use radio buttons to collect a Yes or No answer. This is wrong:
Don't do this. The "No" answer is meaningless, because without consent, the email will already not be sent. Essentially, the user is being asked to consent -- or do nothing. The best interface is a checkbox or possibly a button:
Note as well that this form should only be presented when the user has not given consent. (If the user has given consent, then you should show a form providing for the withdrawal of consent: See below.) As for the affirmative radio button answers, the date/time should be collected on the back end. Additionally, the table should not have a column for Yes/No values. It should be a table called "consents" where each row is just is the date/time. The appearance of such a row means that on that date/time, the user consented. But this is probably not quite enough.
You also want to allow for the withdrawal of consent. In this case the language would be something like this:
Now, on the back-end, you probably want a table called "consent decisions." There is a row with columns defining who consented, what the consent statement was about, a "decision," with values "consented" or "withdrawn," and a column for the date/time of the decision. It can help to have a separate table of consent statements, and rather than showing the literal language on the front-end, use the language from the table so that everything ties up properly. I have seen companies accidentally introduce drift into this process where the consent statement in the database does not match up with the language presented to the user (and sometimes, this language will mismatch paper versions of the consent form.)
By these means, you capture affirmative answers to decisions and consent decisions without confusing the user and you represent them in the database in such a way that there is clarity about the time relations to the decisions and/or consents.
Last thing: The UK has a great document (citing relevant portions of the GDPR) that outlines how consents should work. Consent must be
On another page, they note that you should consider refreshes of consent:
You should also consider whether to automatically refresh consent at appropriate intervals. How often it’s appropriate to do so will depend on the particular context, including people’s expectations, whether you are in regular contact, and how disruptive repeated consent requests would be to the individual. If in doubt, we recommend you consider refreshing consent every two years – but you may be able to justify a longer period, or need to refresh more regularly to ensure good levels of trust and engagement.
If/when you change the consent statement, you will need to re-solicit consent again for the revised language. You will need to ensure that your back-end can support the semantics of the older consents if the user has not had an opportunity to re-consent.
Enjoy.
comments powered by Disqus