Designing for Un-usability

Twice in the last week, I've found and enjoyed posts about - for lack of a better term - un-usability.  Each represents a key principle for when and how to take 'un-usability' into consideration as a design element.  We spend a lot of time looking at usability principles - making things as simple and efficient as possible for the user.  But there are times when a little thought toward un-usability can go a long way.

1. Design for un-usablity because using the product is a bad idea.

The first was Erik Askin's "Designed to Annoy" cigarette packaging.  He carefully determines what makes a cigarette package usable: convenience, branding, and portability.  He then turns these 'usability features' on their ends, creating a package that is difficult to open and share; brands poorly; and can't be put into a pocket.


2. Design for un-usability because malicious users take alternative paths.

The second was WIRED's article about physical security failures at DefCon.  Some very expensive and theoretically 'high-tech' locks were brought down by simple, efficient, and non-technical means. All of these were ways around the intended use.  The manufacturers may have tested extensively the direct 'intended' paths for their vulnerability, but without testing for and uncovering those alternative paths, the locks are very vulnerable to attack.


3. Design for un-usability because you need the user to slow down and be aware of the process.

In my work in healthcare, there were many times when we struggled to slow the user down.  For example, if a doctor is entering a prescription for a drug with a known interaction with one of their existing prescriptions, there needs to be a warning in the software.  Triggering a little popup window crammed with text and a simple "OK" or "Dismiss" button is easily avoided and overlooked.  Some things that might work better:
- creating a timer on the window, so it can't be dismissed
- breaking down the warning into separate points that have to be acknowledged individually
- making the dismiss/approve question and associated buttons deliberately varied and complicated, so it has to be read each time before the correct button can be chosen.

this was first published in August 2010.