When More Friendly Is Less Friendly

Everyone is talking about TONE these days, not only for web pages but for apps and operating systems. The notion is that now, more than ever, text that users see on the screen should be friendly and human.

Well, fine. We in the UX and UI text biz have been saying that for decades. Nice to see that the industry has finally caught up to us.

However, it's another thing when the style guides for that tone are driven by management and inflated by marketing and, as usual, the last folks who get a word on the matter are those people for whom language really matters, the writers.

The fact of the matter is that not all users need or even like sizzle. Snappy tone doesn't fit with every scenario or every product. And when it comes right to it, when you have non-writers at the wheel, the play of language design and visual design can get downright counterproductive.

Here's a case in point.

Everyone by now knows how a check box functions and what it means. It works the same whether on paper or onscreen. You check the box to specify that you want the item, or uncheck it if you don't. It's beautifully simple. The only text you need is the label that tells what you're choosing or rejecting.

But what if the design mandates that check boxes are too "robotic" and should be changed to on/off switches? Skeumorphism aside, these controls are not intuitive without labels. Words must be used to distinguish one position from the other. Depending on how the original label is worded, Yes and No might be sensible for the on/off positions, or perhaps On and Off. But either pair conversely affects the label text too; they have to logically fit the English syntax.

Especially troublesome are options that have been worded in the negative. Now, this is something that at least Microsoft Style has recommended against for some years, but of course it still occurs.

Understandable, if a bit odd:
Do not print [ ]
(User thinks: "I do want to print, so I'll leave that blank. Although I wonder why it doesn't just say "Print"?)

"Friendly" double negative:
Do not print [No]
(User thinks: "Hmmm...does that mean 'No, I do not want to not print'? That's weird.")

"Friendly" nonsequitur:
Do not print [Off]
(User thinks: "Hmmm...does that mean turn printer off? Or...what?")

Below, the simple porting of a control from a desktop app design to a new, web-based design, necessitates a new label, which is supposed to equate to a friendly, human "experience."

Here it works pretty well. When you click the slider switch to No or Yes, it answers the implied question of the label. Still, the option on the left is phrased negatively, so what does it mean to choose No? It would be a lot clearer to word this as "Task effort IS equal to..." and change the default to Yes.

Another thing to watch out for is labelling consistency. Yes and No work well with verbs because the question is implied: [Do you want to] specify production order?   However, "Cost category" is a noun, and Yes and No is ambiguous at best. 

Another issue arises when some check boxes are not turned into switches - particularly if sitting cheek-by-jowl with switches! Is it intentional? If so, why? 

Or, for that matter, why not go whole hog and change Yes/No dropdown menus to either a check box or a switch?

But those are design issues. This being a UI Text blog, my main bugaboo is trying to reply to a non-question with a Yes or No, especially when a labelless check box was doing the job simpler, more elegant, and - dare I say it - friendly manner.