Learnability and common sense

I’m known as a bit of a stickler for having solid theory behind my designs.

One of those theories, or heuristics, is learnability. A system must be learnable; a user must be able to figure it out and remember how to use it over and over again.

Learnability is one of those heuristics that seems like it would be easy, but is actually quite a challenge. For something to be learnable, we need to know both what the system requires the user to know and what knowledge the user already has. (UIE has written well on this topic in their article “Riding the Magic Escalator of Acquired Knowledge“.) We don’t need to teach users what they already know, but we can’t assume they have knowledge they might lack or they won’t be successful. Many users only have so much patience, and we can’t wear it out by closing  giant knowledge gap just to teach them our system either.

We’re at our most dangerous as designers when we assume that everyone knows what we know, and that our designs are easy to learn because we used common sense.

“Well that’s just common sense.”

Ah, common sense, which much like the Moral Majority, is neither. When we first start designing, we often design things the way that we use them or the way we’ve seen them used, rather than the way that works best for the user. UIE calls this stage “Self Design” in “5 Design Decision Styles“.

I know how a doorknob works. I’ve been using doorknobs all my life, I’ve installed them, I’ve removed them, I’ve got a strong mental model for what they look like and how they behave.

This, for example, is a door knob.

Up until about a year ago if you had asked me to go pick out a doorknob for any need, this would be the doorknob I would have picked. Why? It opens doors. Everyone knows how to use it. It’s ubiquitous. It’s just common sense.

Then I got into an argument with a feisty kitchen implement and spent a few weeks with a finger wrapped in bandages.

And suddenly everything I knew about doorknobs changed. If you can’t grip a round doorknob, it doesn’t turn. You need to be able to grab and twist and push (or pull) and that often needs all the fingers. Doorknobs are really close to doors (surprise!) so it’s easy to whack already-injured fingers on them. In summary, for a certain audience, the classic doorknob is not a common-sense solution to door opening capabilities. It is a total pain in the ass.

When we make design decisions based on our own common sense, we’re really saying “It’s what I know works for me.”

Now here’s another doorknob:

This one doesn’t require me to twist the doorknob. If it opens out it doesn’t even require me to grab the doorknob, just push down the lever and push the door out.

The ADA National Network recommends the following for door handles:

Door hardware must not require more than 5 lbs. of force to operate. It must also be operable with one hand and without tight grasping, pinching, or twisting of the wrist. Lever handles and some other types comply with this requirement.

And this is the difference between something being learnable because of “common sense” and something being learnable because we’ve researched its impact on users: in the first situation we consider only what we’ve seen, heard, and experienced, and in the second we consider all users, especially the ones that aren’t us.

UX is not a fancy word for common sense.

What makes something learnable?

To be learnable, a system must^[1]Thanks to Richard Dalton, Andrew Hinton, John Ferrara, Patrick Lowery, Gina Puzo, and many others for teaching me what they know :

• Use a consistent visual, linguistic, and interactive vocabulary
• Match the user’s mental model as much as possible
• Give the user a sense of environment and direction (to make it navigable)
• Provide comprehensive functions and control operations
• Provide help when and where the help’s needed

Continuing our discussion of doorknobs, if we were to introduce a door opening device that we wanted people to learn easily without instructions, we’d start by making the doorknob enough like other doorknobs to be recognizable as a door opening device.

If I’d never seen a lever-type doorknob before, I’d still suspect that it was for opening doors because it uses a consistent visual and interactive vocabulary as other doorknobs I’ve seen. For example, doorknobs are generally a specific heigh and distance from the edge on a door. It turns, it makes clicking noises, and it requires pushing or pulling.

Were I to come across a series of five holes drilled into the center of a square steel panel in a wall, I would not expect the holes to be a doorknob, nor the plank to be a door, because my mental model of a door is a tall rectangular panel hinged on one edge with a protrusion for pushing and pulling on the opposite edge. Any new door opening apparatus I introduce to the world needs to take the user’s mental model into account.

On well-designed doors, the shape and style of the doorknob tells us how to navigate its interface. When things are poorly designed, we get Don Norman doors. Well designed door interfaces offer affordances that help us recognize their use.

A good doorknob allows the user comprehensive control over the door. Imagine the opposite: a door that had, say, a bolt lock in it to allow for locking or unlocking, but not to pull or push the door. It’s great that one can unlock the door, but somewhat substandard to not be able to open it once it’s unlocked. Doors must be openable; that’s a base feature. Locking and unlocking generally come second.

Finally, some doors still need to provide the user help. This may not be the fault of the door designer either — it may be a result of the environment. My favorite Asian Fusion restaurant has a giant “PULL HARD” sign on its door because something (the air pressure in the restaurant? a slight gradient to the door frame? Bad luck?) makes yanking the door open much harder than the standard door. The help provided is contextual: it’s on the door. It’s immediate: big noticeable letters. It’s effective: you immediately know what you did wrong.

Some tips for learnability

As you might guess, what will work to make one system learnable may make another system a disorganized mess. The tricks that follow generally help more than they get in the way.

Know how often your audience will use the system

A user will check their email a few thousand times a year in an office setting, but will probably only set up a 401(k) retirement account a few times in their life. Someone will memorize how to check their mail after the first two days, but will forget how they set up their first 401(k) by the time they need to set up their second.

Email has to be learned once, so learning it can be a little weird or obscure or require a job aid. Setting up retirement accounts need to be learned every time the user goes through the process.

Take it slow

It’s better to break up a longer process into small chunks for unfamiliar users than it is to present a giant form or application. Ask a few questions, validate them, move on to the next part, and help the user build confidence that they can make it through the system.

Present a consistent (friendly!) look and feel for error messages

If the user doesn’t know how to use the process, they’re going to make mistakes. Users will probably spend more time deciphering your error messages than you will creating them. Put effort and time into that task. Follow the 4Hs of Writing Error Messages.

Be consistent within and outside of your system

Consistency is important when learning. You want the user to recognize what success is when they reach it. You want them to recognize error messages when they display — and to know if X cleared the last error message it’ll probably clear it here too. You want to present consistent-looking buttons, links, etc. so the user knows what’s interactive and what isn’t.

But it’s not enough to be internally consistent (although it goes a long way believe me!) You also need to be at least somewhat consistent with the outside world.  For example, as Apple, Google, and countless others began developing touch gestures for phones and tablets, they had to keep an eye on each other’s for — and we had to keep an eye on all of them. It wouldn’t do at all to have a gesture that means “duplicate” on one platform mean “delete” on another. We just can’t guarantee that users will only use one platform.

Research, research, research

If you’re not sure how often your audience will visit the site, do the user research necessary to find out.

If you’re not sure how frequently an interface element is used, do some competitive analysis on direct and indirect competitors and whether they use it.

If you’re not sure whether your work is consistently presenting the design, take screenshots and compare them. Grab a screenshot of every error message in a sign-up process, for example. Do they all use the same tone, voice, visual design, and interactions? If not, are the differences justifiable?

Usability test. Get people in a room and have them try to use your process. Learn what you don’t know you don’t know. Where do they get lost? What doesn’t work? What “common sense” do they bring to the interaction that you didn’t know about?

In conclusion

Learnability sounds like an easy heuristic to master, but we often get in our own way by designing for what we personally know, what we physically can do, and what we find easy to learn instead of what our users know, do, and learn.

Nothing’s common sense unless it’s common sense to the user.

There are both heuristic guidelines and tips and tricks we can use to better design learnability into our systems, and many many books and articles to read. Go, explore, and build more learnable systems.