Good interfaces are not, in fact, like jokes

Published

Some of the most insidious design advice ends up sticking around because it sounds true. Or clever. Or both.

I suppose this is true of all bad advice.

One particular piece of true-sounding, clever-sounding, and ultimately dangerously-reductive advice that irks me is the trope that compares good interface design to a good joke.

You might have seen it in this form:

A user interface is like a joke. If you have to explain it, it’s not that good.

You might have even seen it on a coffee mug!

It seems to have been coined in 2014 by a bloke named Martin LeBlanc. I don’t know Martin from Adam, and I’m not writing this to knock him in the particular; I for one have begged people not to take my own tweets too seriously. Still, Martin seems fond of the tweet. It’s pinned to his profile — surprising, perhaps, given that he seems to have “sold” it through some blockchain nonsense? I’m not going to try to understand 😂 — as well as to the profile of, get this, IconFinder.

That’s right: The line about good interfaces not needing explaining is from the CEO of a company that sells icons, those inscrutable little illustrations far too many many designers insist on using in lieu of, you know, words.

On the surface, Martin’s notion sounds true enough. Intuitive interface, hurrah! We all want doors that open the way we expect, elevator buttons that take us where we want, forgiving forms that submit successfully the first time. Fine, fine. 

My concern is that not all interfaces are doors. Nor elevator buttons, nor simple forms. Plenty of interfaces and patterns, even “simple” ones, have a learning curve. We often just forget that we had to learn them.

Further, I’m not sure that a joke has necessarily failed if it needs explained. Explaining a joke can make it accessible to an audience who didn’t understand it previously, therefore making them feel included and part of an in-group. It’s all well and good for a teenage lunch table to say “you had to be there” when someone asks what’s so funny, but it’s not as good of a look for a SaaS app that wants to be as inclusive as possible. And if truly anyone can understand the joke right out of the gate? Absent any other context or knowledge? Well, that’s probably some not very sophisticated pee-pee poo-poo humor.

The truth is this: Few experiences are truly intuitive. We have to teach people how to drive, and how to sing, and how to make love. And we can all bring to mind people who never did learn those things very well, I’m sorry to say.

This erroneous trope, that good interfaces don’t need explaining, is frequently weaponized against the guidance of UX and technical writers. When designers internalize this bad advice, they end up making exactly the wrong choice: in an effort to make interfaces seem more intuitive and easy to use, they remove and avoid labels and explanations, therefore making interfaces harder to use for all kinds of audiences. And here I’m just talking about interfaces that are actually on the simple side. Some interfaces will always require learning and explanation. this might be because they have complex and powerful features, or are highly-customizable, or introduce a new paradigm, or are part of a mission-critical system or activity, etc.

Regardless of the complexity of the interface itself, I believe that all interfaces, and the experiences they are part of, can benefit from being explained. As I wrote in Writing for Designers:

Even if your design were simple, beautiful, and intuitive, writing can take it one step further. Writing can reinforce how you want users to think about your design. Writing can explain the approach or philosophy that underpins your design. Writing can guide users through complex processes. Writing can even help cover for the quirks and compromises in our designs— hopefully not our first resort, but valuable nonetheless.

If you’re out there fighting for your users for a bit of an explanation, a tooltip, a how-to guide, an empty state message, I say: Godspeed, friend. I’ve got your back.