Usability Could Use Some Usable Heuristics

I’d imagine that the world’s worst presentations are given by the developers of presentation software. (I certainly sat through a staggeringly poor presentation by SGI folks during SGI’s heyday.)

I can’t find a good set of usability heuristics to beat crappy software over the head with (you must fix Blender because Tog says so), so I thought I’d write my own and pretend I’m some kind of authority.

So here, in order of decreasing importance, are my simple rules of usability.

  1. Consistency. It’s the bugbear of small minds, but guess what, a lot of users have those small minds. Don’t just be consistent with yourself—be consistent with as many things as possible.
  2. Visibility. If you can’t see it, it might as well not be there. More advanced users will look in more places, so make the stuff idiots need to see bleeding obvious. But see item 4—making everything visible can be just as bad as hiding stuff.
  3. Speak to users in their language. If users think about “folders” and “projects” don’t call them “directories” and “objects”. Don’t know what the users call things? Find out.
  4. Progressive Disclosure. Show the stuff they probably want/need to see and allow the rest to be disclosed if needed. Show the functionality they probably want/need to use and allow the rest to be disclosed if needed. Make the stuff you show as powerful and general as possible and you may not need to hide much at all.
  5. Forgiveness. Make it hard to screw up (try to detect and prevent errors before they’re made), make it easy not to screw up (give useful feedback), and give people a way out if they screw up anyway (undo).
  6. Beauty & Simplicity. Ugliness is distracting. We don’t like ugly things for a reason, often “ugly” is shorthand for real problems—disease in organisms and inconsistency and carelessness in software. A consistent program is generally a tidy program and untidiness is the easiest form of ugliness to eradicate.
  7. Use natural mappings. The classic example of arranging stovetop burner controls in the same layout as the burners is one of Don Norman’s most memorable examples (along with the seat controls from his Mercedes—now common in the industry—and the 3 Mile Island reactor control room), but natural mappings don’t just apply to the real world. If you’re using color, shape, or layout as mappings in your product, and you’re consistent about them, these become natural mappings. If red means danger here and awesome there, you’re violating consistency and failing to use natural mappings.
  8. Maximize Generality, Minimize Steps. These (often conflicting) goals are powerful tools for rethinking and improving an interface. If you can do more with less you’re almost certainly improving your UI. Improving generality (e.g. providing a dialog that does more things) is only good if it doesn’t increase steps and vice versa—that’s the key. (Imagine you could easily put all the Photoshop filters into a single dialog, but it would have a menu of all the filters in it … so you’ve created a very general dialog, but you haven’t saved any steps. Another way I put this is avoid non-decision actions. When the user has to do something, it should reflect a decision they’ve made and not just a mandatory step.
  9. Smart Defaults. When something needs to have a default value, try to pick that default intelligently (but make it easy to change). Defaulting to the user’s last choice is often a simple, effective option.
  10. User Errors are Crashes. If a user makes a mistake it’s equivalent to (and often more damaging than) a crash. Treat it like one.
  11. Avoid Preferences. Configuration choices are often a design failure. Is there a way to make this not an option? Don’t be an asshole, but have an opinion.
  12. Wizards. These are generally a sign of design failure. Why isn’t it obvious how to do what it is the Wizard helps you do? Can you do the thing the wizard does without the wizard? Can you undo it?
  13. Online Help. It ought to be good and largely unnecessary.

There you are, it goes up to 13. And Blender has addressed almost every one. Perfect! (Edit: when I first wrote this, there were 11, and Blender violated all of them.)

Post Script: this article is very old, but it’s still 100% accurate up to the last sentence. I’d love to take credit for it—I did actually say most of this stuff on the Blender forums at the time, but I was flamed by so many users with Stockholm Syndrome that I doubt my suggestions received much notice.

Blender has since around v2.8 (it’s now up to 3.5.1 as I write this) pretty much addressed all of these points. It’s still overwhelmingly complex, but almost every single area has been hugely improved. Kudos!

Changes Resulting from Nielsen’s Heuristics

July 13, 2023

I was recently made aware of this article by Jakob Neilsen, apparently dating back to 1994 (but not really, see below). It’s very good (and more than makes up for this egregious tripe he posted in 2009 and which I have previously lambasted). So, I made some changes to this list.

I’ve omitted Nielsen’s User Control & Freedom because I think it’s too vague. It’s like saying a user interface should be “intuitive” or “good”. Yes, but what does that mean? That’s why we have heuristics.

I moved Visibility up from 4 to 2 after reading Nielsen’s post. He has a different version of this as his top item, and that’s fair—until you consider things like audio interfaces.

I added item 3, Speak to Users in Their Language as the key takeaway from Nielsen’s Match between system and the real world which I think is badly worded to the point of being misleading. Don Norman’s “simple, smooth system model” (per Design of Everyday Things) is a point Nielsen really wants to make.

I added item 7, Use Natural Mappings, reflecting another point from Nielsen’s Match between system and the real world.

I noticed that the earliest version of Nielsen’s article (dated 1995, but posted on the web in 2012 or 2013) cites First Principles of User Interface Design by Bruce Tognazzini, who specifically mentions Fitt’s Law. While this is rather specific to pointer-based interfaces with hard edges—e.g. generally not touch interfaces or audio interfaces—the underlying principle—that some steps are harder than others—is very important. Clicking on a pixel is a much nastier step than swiping from the right edge of the screen.

One more thing: it’s been bugging me that I missed this article back in 2007 when I wrote the original post, especially since I’m a huge fan of Don Norman and Bruce Tognazzini and pretty sure I googled extensively for usability heuristics. So how did I miss this 1994 article? I don’t think I did.

I then checked and found that NN/g was founded in 1998, so the odds this post was there in 1994 seem… remote. I don’t doubt Nielsen based the article on something dating back to 1994, but was it online?

Well, the Wayback Machine doesn’t seem to think it existed before 2012, and if you look at the old versions, the date changes as does the copyright! The first post is copyright 2005, and claims to have been posted in 1995. So somehow it got older as it got newer. And the original version cites a (better) Tognazzini article (the link dates to 2003) but says “The list is slightly too long for heuristic evaluation but serves as a useful checklist”—it’s probably less than half as long as Nielsen’s current version (and that’s not including the explainer videos!).

It looks to me like Nielsen had a mailing list (“Jakob Nielsen’s AlertBox”) to which he posted an earlier version of the article back in 1995 (not 1994). I’m guessing they dumped this content onto NN/g’s website in December 2012 in some way, shape, or form. But the version from 2013 cites a Tognazzini article that may be as old as 1999, but based on the title it was a 2003 version.

When I wrote this article, I was involved in, basically, a flame-war with the Blender community over Blender’s egregiously bad user interface, and a lot of their responses to my criticisms came down to “well, that’s just your opinion”. I would have loved to find this post on Nielsen Norman Group’s website in 2007—after all, who was I to make judgments on a given product’s user interface?—but AFAICT the NN/g website didn’t exist, this post hadn’t been written, and I people backdating content to be pretty annoying.