Making happy users

"Make the right thing easy and the wrong thing hard." If designers followed that one clear principle, there'd be a lot more happy users. I'd get a lot more work done instead of struggling with a counterintuitive interface. Writing software would be easier because APIs would simply make sense, with less chance of blowing up at runtime. I could use my car stereo.

That mantra is one I hear every day, from my horse training coach, as the foundation for "natural horsemanship" principles. But I can think of a certain programming language and certain software and hardware vendors that could stand to spend some time hearing my trainer repeat that over and over and over...

Notice that the chart does NOT say, "Make the EASY things easy." It says, "Make the RIGHT things easy." And those things might indeed be quite complex. "I Rule" experiences don't come from doing brainless trivial tasks. (But you can certainly have an "I Suck" experience when trivial tasks are made hard.)

The goal is to make it easy for the user to do the thing he really wants to do, while simultaneously making it difficult or impossible to screw things up. Every screw up, road block, confusion takes the user out of the flow state. It stops him from the thing he cares about, which is NOT how to use whatever tool, device, software it takes to do it.

Yes, I know this goal is dead obvious and "duh." But why are we drowning in products that seem to be made by those who have forgotten this? Or at the least, by those who were unable to do it...

Some examples of "make the right things easy and the wrong things hard" are:

1) A strongly-typed language that stops you from assigning a String of characters (like, "cheese") to a variable that you said was supposed to hold a number (like 42). Or a language like Java with an "exception" mechanism that forces you to acknowledge that bad things (like, the network is down) can happen.

[Yes, you give up other things in exchange for this "protection", so I'm not saying strongly-typed languages are right for everything...]

2) A product whose physical design makes its use obvious and natural, like a jack that fits into only one kind of port, and in only one, obvious orientation.

One variant of this is the concept of affordances, an example of which is a cup with a handle. The handle is said to afford grabbing it--which is the right thing. But a car dashboard with a nice flat surface affords the wrong thing--setting things on it (putting light papers on the dash can reflect on the windshield and make it impossible to see, not to mention what it does to your driving when things go sliding off the dash).

It's still possible to make products whose "correct" use is easy, but which also invite incorrect or even dangerous use. If designers follow only half of the principle ("make the right thing easy") but don't "make the wrong thing hard", then you might have a 50/50 chance that a user will, say, blow up if they he plugs the X into the Y.

3) An API design which exposes the highest-level interface rather than a huge pile of lower-level calls (which could make it way too easy, for example, to call the right things in the wrong order), and whose methods/operations are named well! Half the reason our books sell so well is simply because some of the Java API designers used names that practically beg you to do the wrong thing.

4) A school program that relys on interesting group projects rather than dull, rote memorzation homework. And make those projects something you do mostly in class!

5) And speaking of kids... I try to follow this with the teenagers as much as possible, and one of the simples ways is to have a reduced rule set. The fewer the rules, the harder it is to break them (i.e. the "wrong" thing), and the easier it is to adhere to the ones that are there.

Important note: remember that this isn't simply about making everything easy or dumbing everything down! If I'm working on a video edit, for example, the video edit is where I want my brain bandwidth to go, not how to tell the software that the edit should go here. The point is to make the thing I want to do... the "right" thing... easy, but keeping that "right" thing as complex and sophisticated as it should be. I want my video editing software to give me enormous power, but I want to focus all my brain energy on deciding where--and how--the edit should happen, and have the act of causing the edit to take place as natural as possible.

Every moment I spend trying to figure out the interface--or worse, trying to recover from a terrible mistake the software allowed or even invited--is a moment not spent creating something. Doing my real work.

Games, for example, should not be easy, but the interface in which you play the game should be. The game should allow me to stay in character and not break the flow by forcing me to deal with a user error (as opposed to a "character" error) or by forcing me to stop and look at the manual again...

Also, this does principle/mantra does NOT totally apply to learning experiences, with the exception of tools used to deliver the learning experience. Much of the most memorable learning comes explictly from failures and mistakes--things that did not match your expectations. And I sure don't want my next airline pilot to have had training that supported only the right thing (although many industrial disasters have been linked to cockpits and controls that made the wrong thing easy).

Sometimes we learn through struggle, but for the love of Smurfs, please think long and hard about which things the user should struggle with, and which things should get the hell out of his way.

I'm not saying that I know how to do this well either, but I can sure think of a zillion things I interact with where I think, "why on earth did they name that method in a way that suggests the thing you want but... does the opposite?" or "if they'd only flipped the direction of the switches, they'd be mapped perfectly to the direction of the thing they control (like the "up" switch moves things forward, and the "down" switch moves things back) or "if they didn't want you to sit on this thing, why'd they make it look and feel like a bench?"