What voice should an option you don't want users to change be written in?

Question

We have a form with a bunch of options that impact how our service will work for a given account. Most of them are positively-voiced questions ("Allow this to happen?"). There is one option that prevents users in the account from being able to change their own settings. We want to discourage the use of this as it significantly reduces the value of the service to the users of that account.

I'm trying figure out if this should be a negatively-voiced question (left-hand option) or a positively-voiced question (right-hand option). I know negatives are harder for users to comprehend while reading quickly. Could this "speed bump" cause the user to leave the setting at the default?

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 1

I'm not sure you should rely on a copy change alone (or even if it worked, it may not be worth the added confusion - see @joe larson's answer). You might try instead calling out an explicit warning:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 2

I get what you are trying to do here. But if you flip only one of a long list of "Allow? Yes/No" to "Disable? Yes/No", instead of discouraging undesired behavior you'll most likely just get confused users doing something they did not intend.

This is similar to those jokes where you ask a long string of questions with a similar answer and then throw in a curve ball to get that same answer.

It's also reminds me to grocery store checkouts which typically ask "Do you want cash back? Yes/No" and then "Confirm charge of $1.23 Yes/No". Most of the time you are going to press "No" then "Yes". But this still trips me up from time to time.

This can even be a problem with a single choice. About a year ago a Java plugin update came out with some security improvements. The result was that users would load an applet which they'd been using happily for years, and a security warning would come up. The default choice was essentially "Yes", but that "Yes" meant "Yes, I want to not use this applet". This caused great confusion for users and extra work for support... Though possibly this had more to do with users reflexively barging through security warnings without understanding them than anything else [which is kind of what you are dealing with here].

So in general, I'd say the principle is first make a list of yes/no choices consistent in their positivity/negativity. Second, when possible make "Yes" mean "move forward/confirm/continue", except when it violates the first principle.

One totally different solution would be to move this question to a separate area and deal with it using a different UI control (toggle button, dropdown, etc..)

Answer 3

In our UI, we changed the responses to match the tone of the question: Allow/Disallow vs. Enable/Disable vs. Yes/No.

The UI itself could still be radio button/slider/(your favorite). Make sure that the default answers are "internally consistent" - i.e. most secure, most useful, etc. since when in doubt, users dont change them.