The Paradox Of Intuitive Product Design
“Simple” is an overloaded term when it comes to software design. Everyone knows that simple trumps complex, but in what context? Architecturally, “simple” means generalized, abstracted, shared, service-oriented, etc. But when talking about the UI, “simple” usually means “intuitive”. Unfortunately, making a product intuitive ain’t simple.
When someone says a product is “easy to use” or “intuitive”, they mean people instinctively know how to use it — that information appears where they would expect it, that clicking a button does precisely what they would expect it to do — that they won’t have to think in order to do.
Making software intuitive requires that the system behavior is aligned with people’s expectations, but our instincts are often based on complicated behavioral patterns, and those patterns are wrong more often than we pretend. This issue is referred to as cognitive bias. Here are some examples of our how simple rules of thumb can go awry and out intuition is frequently wrong.
Big causes yield big effects. People literally shake dice harder when they want to roll a bigger number.
Things should average out in the long run. If a roulette wheel comes up black 10 times in a row, people will assume red is “due”.
Categorization is the best method of organization. People will segregate a spectrum into categories, even if those categories don’t really exist. If you give people a collection of pencils each sharpened to a different length, they will invariably organize them into categories: short, medium, and long.
The best decision is the one with the most pros and fewest cons. People buy big suburban homes because they can imagine a hundred (unlikely) purposes for the extra space, but discount the extra long commute because it’s just a single con, even though they will experience it thousands of times over.
Big is big and small is small. People will either vote for or against a bill regardless of whether it costs $100B or $800B — both numbers feel so huge, they are effectively the same.
There are plenty more cognitive biases out there. (It’s really fascinating stuff, in case you want to read more.) Now, back to product design: when designing software to be “simple” for the user, you need to align with these types of heuristics despite their technical inaccuracy.
Your software still needs to function properly, but you must find a way to make it work while generally matching people’s natural (yet flawed) world view, and that can be difficult and complicated for a product manager or UX designer.
The rubber hits the road when deciding things like button behavior, organizing content and functionality into tabs, or creating “intuitive” flows. Consider the top button on the iPhone. What is it? It’s just a power button, right?
- When held down, if the phone is powered off (completely), then turn the phone on.
- When held down, if the phone is powered on, then offer to turn the phone off.
But if you think about it longer, it’s also the on/off button for the UI, toggling sleep/awake mode.
- If the phone is powered on, but the screen is off, offer to turn the screen on (enable the UI).
- If the phone is powered on and the screen is on, turn the UI off.
And it continues: If the phone is ringing, pushing the button will stop the ringer. If pressed twice it will reject the call.
I didn’t know about the ability to silence the ringer when I bought the phone, and I never read the instruction manual. And yet, the first time I needed to silence the ringer, I immediately thought to hit the “on/off button”. How did I know to do that? I didn’t; it was instinct. But I also didn’t ask myself, “how would Apple most likely allow me to silence this call quickly?” In fact, it was the other way around. Apple researched users to see what would be intuitive and then built to match it. Then they took it a step further: all the other state changes (on/off/wake/sleep) are basically permanent, but silencing the ringer is temporary — it applies to that call only. While technically inconsistent behavior, both behaviors are intuitive. If you stop to think about it, it doesn’t make sense. But if you don’t think about it, it absolutely does.
Basically, the top button is the “stop” button: stop sleeping, stop eating my battery, stop everyone from glaring at me in the movie theater. “Stop” is an intuitive concept, but requires a large number of use cases, state transitions, etc. in the software. The actual functionality is complex in order to be intuitive.
Many product designers, and CEOs they work for, make the critical mistake of thinking simple to use means simple to build.
Fortunately, people’s intuition isn’t logical, but it is generally predictable. Think of intuition like an instruction manual that all your users read before using your product. But you don’t get to write the manual, and half of it isn’t as you would have desired. Design with that in mind. Doing so will require extra complexity in the software, but the added complexity will be perceived as “simple”.