Random Usability Fails

There are those that dream of things that never were, and ask why not? I look at things the way they are, and ask why?  Or something like that.
Here are a few examples of the usability fails that I can't help but collect...

Mixed Messages
Here's a great example of mixed messaging in the form of required warning labels on tobacco branding.  This was a price-point poster in the window of a local gas station.  Each brand sported a mandatory caution, like "WARNING: Smoking can kill you."  Fair enough: a caution label followed by a negative statement; that makes sense.
But what's the deal with this guy: "WARNING: Quitting smoking now greatly reduces serious risks to your health."
Wait, that's...a warning?  I guess -but it's confusing.  Here's why:  It's a positive statement in a set of negative peers.  It seems trivial when articulated, but reading down the list makes this statement confusing and out of step.

This hits at the core of an on/off; yes/no; checked/unchecked interface item and how it is presented within an information architecture.  If there are a set of these optional statements, make sure that the set of values are consistent.  If a checkbox means "yes, do it" make sure it's peers in the set are also positively inclined.  Mixing additive and subtractive controls in a set of peers is confusing.  This also applies to the following example, plus a few...

Convention Misuse / Logic Gaff
The intent of this marketing blitz was to promote these two options as mutually exclusive.  They should be radio buttons!  Is this a nerd trap?  Well, yes, but probably not intentionally.  In addition to providing mixed positive/negative statements in a peer group, these two options represent a false dichotomy logic fallacy.  Ironically (coincidentally?), the mistake of using checkboxes fixes the false dichotomy problem, but anyways.

Let's address the two problems individually.  The convention of the checkbox is as an inclusive filter (which in itself sounds like a conflict of opposites and believe me it comes up).  Multiple checkboxes in a group should provide independent and distinct options which can be selected in any combination.  If you have a set of options where only one concurrent selection is allowed, use something else.

The problem of the false dichotomy is a little harder to detect initially.  A set of checkboxes ought to represent the universe of available choices (unless there is a noted exception somehow stated to the user).  It's helpful to ask a client, as soon as I see a set of checkbox filters developing, are these all of the available options?  Stored procedures and complicated query strings can get crazy in a hurry -be sure to think each out and ensure their naming convention and arrangement in the interface helps set the correct expectation, sparing the end-user of herculean feats of logic supporting a simple interface.

Poor Categorization / Misleading Aesthetics

Which one of these is not like the other one?  This is actually a photo from my own house -and I was the offender.  What you are seeing is our chapstick jar in the junk cupboard with a tube of industrial strength adhesive nestled comfortably within.  The other evening I was groping around (it's a tall cupboard) for chapstick and pulled out the superglue (which I had stuffed there absentmindedly earlier -right next to the other 'tubes of stuff').  Jeez.

It can be tempting in an interface to lump like-looking things even though the function they serve is cosmically different.  Categorization is great -one of the best tools info architects have, but miscategorization hijacks the benefit and can lead to wrong choices or misunderstood results.  Or seized lips.