It's the most overused word in any product review. "Make it more intuitive." "Why isn't this intuitive?" "Users said it wasn't intuitive." Everyone nods.
But ... intuitive for whom?
It sounds like a nitpick. It isn't. "Intuitive" isn't something a design is — it's something that happens between a design and a particular person's history with everything else they've ever used.
What the word actually hides
When we say something's intuitive, we mean it didn't need explaining. But "didn't need explaining" only happens because the person walked in already holding a map of how it should work. Intuition isn't a spark of understanding. It's recognition. You're cashing in experience you already had.
Jakob Nielsen put a name on this 25 years ago: people spend nearly all their time on other products, so they expect yours to behave like the ones they already know. Their sense of "how software works" is a composite of everything else, and they hand you that composite when they interact with your product.[1] Match it and you feel obvious. Break it and you feel broken.
There's a sharper edge to this that should worry anyone who treats "make it intuitive" as a patch. People will choose the familiar-but-worse option over the better-but-unfamiliar one, on purpose. Researchers call it the paradox of the active user: we're so fixated on finishing the task in front of us that we won't spend ten minutes learning a tool that would save us hours.[2] Familiar doesn't just feel nicer. It wins.
The cockpit
Climb into a 747 cockpit and you're staring at a wall — hundreds of switches and dials built, apparently, to confuse you. I wouldn't know where to begin.
To a veteran pilot, it's the most natural room in the world.
Same panel. Same switches. Same light hitting two pairs of eyes — and it's the most intuitive interface on earth and a complete brick wall, at the same time. The thing didn't change. The person did.

That's the whole argument sitting in one object. "Intuitive" isn't a trait the cockpit owns; it's a handshake between the cockpit and whoever's in the seat. The 747 loses the tourist because the tourist brought the wrong map, and wins the pilot because the pilot brought the right one. And here's the part teams flinch at: that's not a flaw. Nobody at Boeing lost sleep over the cockpit being unreadable to civilians. They picked their user — a trained professional — and built ruthlessly for that person.
But there's a second floor to this, and it's where the comfortable version falls apart.
In WWII, B-17s kept crashing on landing. Skilled pilots would touch down clean, then somehow yank the wheels back up and grind the plane into the runway. For years the verdict was "pilot error." Then a psychologist named Alphonse Chapanis noticed the crashes weren't random — they happened in some planes and not others. B-17 pilots did it. C-47 pilots almost never did.
The answer was in the cockpit. On the B-17, the landing-gear lever and the flap lever sat side by side. On the C-47, they looked different and sat apart. Exhausted pilots reaching for flaps grabbed gear. Chapanis's fix was almost insultingly simple — a little rubber wheel on one lever, a wedge on the other, so a hand could feel the difference in the dark — and the crashes stopped. He refused to call it pilot error. He called it designer error, and the shape-coding principle became standard across every cockpit built since.[3]
Sit with that. The B-17 pilots were veterans. They had the right map. And they still crashed, because the design picked a fight with a basic fact about people: two identical things in two adjacent spots will get swapped under pressure. Expertise was necessary and not enough.
So the modern cockpit isn't intuitive to a pilot just because the pilot trained hard. It's intuitive because someone spent decades engineering it that way — distinct shapes, consistent placement, controls that map to what they actually do — to fit both the expert's map and the limits of being human. Intuition for experts isn't automatic. It's manufactured. The cockpit only confirms the pilot's map because someone first did the brutal work of getting the map and the machine to agree.
McDonald's
Now flip it.
When the McDonald brothers relaunched in 1948 on their new "Speedee Service System," people hated it. They'd built the fastest food anyone had seen — wait times from thirty minutes down to thirty seconds, burgers at fifteen cents[4] — but the experience trampled every expectation diners had. No carhops. No waiters. No table service. Walk to a window, order off a tiny menu, bus your own tray.
Nobody clapped. Dick McDonald remembered new customers pulling in and leaning on their horns, waiting for carhops who were never coming. For a while the reinvented place pulled fewer people than the barbecue joint it replaced.[5] They had built something better and watched the crowd get angry about it.
That's the paradox of the active user, live. Customers had a working map — this is how you get dinner — and McDonald's was telling them to throw it out. By every rule above, that should have killed the business.
It didn't, for one reason: the payoff was big enough, and they repeated it at enough locations for long enough, that the learning became the new normal. McDonald's didn't match anyone's map. It drew a new one and stamped it onto the whole country, until "ordering fast food" and "the McDonald's routine" became the same sentence. Today it's not the design that breaks expectations — it's the expectation everyone else gets measured against. Kids run the pattern before they can read.
McDonald's won the bet most products lose. But notice what made it winnable: not that it was intuitive — it wasn't — but that it was learnable, repeated, and worth the cost of learning.
The reconciliation
Here's where the stories stop fighting.
Both run on maps. The cockpit wins by matching a map its users already carry (and earning that match through design). McDonald's won by building a map and handing it out until it was everyone's default. Opposite tactics, same dial — one borrows the map, one prints a new one.
And both lean on the thing the word "intuitive" keeps getting confused with: easy. They aren't the same. Intuitive lives in the first thirty seconds — do you recognize this? Easy lives a thousand reps later — how little does this cost you now? The bridge between them is one of the most reliable findings in psychology, the power law of practice: time-on-task drops predictably the more you do something.[6] Brutal on day one, automatic by day one hundred.
The cockpit was built for people who'd already climbed the curve. McDonald's got people to climb a new one. Both end up feeling intuitive. Neither got there by accident, and neither is intuitive to everyone.
A keyboard shortcut is the pocket-sized version. Opaque the first time — not intuitive at all. The fastest move you've got after a thousand presses — maximally easy. Same key combo, different spot on the curve. "Is it intuitive?" and "is it easy?" are questions about two different days in someone's life with your product, and mixing them up is exactly how teams optimize the wrong thing.
The questions to actually ask
Who is this for — really, not on the pitch deck? Who sits down with it in the first six months, and what map are they holding? Boeing never pretended the 747 was anyone's first plane. Pick the user that precisely, and the rest gets easier.
Are you matching a map or building one? Both are fair. They're nothing alike to execute. Matching means worshipping convention and killing surprise — the safer bet, because breaking expectations costs you. Nielsen Norman once found that just centering a logo instead of left-aligning it made people roughly six times slower to find their way home.[7] A tiny break, an ugly bill. Building a new map means betting on onboarding, repetition, and patience while people climb — a longer game, with a steeper cost if the payoff isn't there.
If you're asking people to learn, is the payoff worth it? This is the question McDonald's nailed and most dead products got wrong. Lose table service, gain speed and a fifteen-cent burger was a steep enough reward to drag people up the curve. A learning curve isn't the problem. An unearned one is. If you're going to fight someone's map, what's waiting on the other side had better be wildly better — not just different with a fresh coat of paint.
The cockpit was never trying to be your first airplane. McDonald's was never trying to be a diner. Both became second nature to the people they were built for — one by meeting the map already in their heads, the other by drawing a new one and teaching the world to read it.
That's all "intuitive" ever means. Not obvious to everyone. Obvious to the right person, at the right point on their curve with you. Build for that person. Be honest about who they are. And if you're going to make them learn something new, make sure the other side is worth the climb.
Sources
[1] Origin of Jakob's Law — users spend most of their time on other sites and expect yours to work the same way: Jakob Nielsen, Designing Web Usability: The Practice of Simplicity (New Riders, 2000) ↩
[2] The 'production bias' toward familiar methods over better unfamiliar ones: Carroll & Rosson, 'The Paradox of the Active User,' Interfacing Thought (MIT Press, 1987) ↩
[3] The B-17 landing-gear/flap study, the coining of 'designer error,' and shape coding: Alphonse Chapanis, 'Psychology and the Instrument Panel,' Scientific American (1953) ↩
[4] The Speedee Service System cut service from thirty minutes to thirty seconds; fifteen-cent hamburgers (1948): Britannica, 'McDonald's'; EBSCO Research Starters, 'McDonald's restaurants' ↩
[5] Dick McDonald's account of confused customers honking for absent carhops; relaunch initially drew fewer customers: Lisa Napoli, Ray & Joan (Dutton, 2016); Smithsonian ↩
[6] The power law of practice — time-on-task drops predictably the more you do something: Newell & Rosenbloom, 'Mechanisms of Skill Acquisition and the Law of Practice' (Erlbaum, 1981) ↩
[7] Centering a logo instead of left-aligning it made users roughly six times slower to find their way home: Nielsen Norman Group, logo placement findability testing ↩