#simplify. This word was on the wall, next to #datafy and #customer-obsessed along a couple other values of a company where I worked. I came across it every day. I nodded along in meetings when someone mentionned it, and I’ve definitevely used it in a handful of decks. This was not the first time I came across this mantra over my career, but this time, it was for everyone to read on a wall, branded as a core value.
And yet, the more I applied it to the problems I was actually researching, like navigating a financial product, understanding health benefit, buying a property, tackling an internal process even, the more I felt something was off. Don’t get me wrong, the issue I have is about the word itself, not about the intention.
The problem with “Simplify”#
“Simplify” is a seductive word, but also a dangerous one in product design. There are things that you cannot simply simplify. Like acquiring a primary residence for instance. There are legal obligations, notarial steps, cooling-off periods, mortgage conditions, insurance requirements, and other regulations that exist precisely because the stakes are big. Simplifying them, like actually removing those frictions, would not make the process better. It would make it dangerous. You can’t just buy a house like you would buy a pair of pants.
When a Product team says “we need to simplify this flow”, they usually mean (1) remove friction, or (2) hide complexity. Those are legitimate tactics, but they can produce something troubling if done poorly, or in the wrong context. I’m gonna go with Don Norman for this one: there’s a distinction to be made between complexity and complication. The former is an inherent property of the world, the latter is confusion caused by poor design.
Removing complexity from an interface doesn’t make it go away. It moves elsewhere: to the user’s mental model, to the support team, to the legal fine print, etc. and it’s likely to blow up in your face at some point.
Simplexity vs Simplicity#
The concept of “simplexity” comes from Alain Berthoz, who published a book in 2019 called “La simplexité”. Berthoz is a neurophysiologist, and he studied how the brain handles complexity. The gist of it is that biological systems don’t solve complex problems by making them simple. They develop sophisticated mechanisms to act efficiently within complexity. They include inhibition (actively suppressing the irrelevant), anticipation (acting on probabilistic predictions rather than waiting for certainty), and the willingness to take a longer route when it leads to more elegant, robust solutions.
Of course, users are not neurons (well… kinda), but I like the idea that our tiny thinking units can work their way around the complexity of our world. I also see it as we’re all capable to deal with complexity without having to rely on dumb-downed or overly-explained stuffs: we can manage complex systems, and ultimately master them instead of avoiding them.
Design that ignores this treats complexity as the enemy of the user, when the real enemy is confusion.
In design, when we simplify at the expense of user literacy, we’re not doing UX. We’re doing paternalism through a sleek interface.
Simplexity applied to design already exists#
The good news is that designers have been practicing simplexification already, under other names. Here are 3 patterns that make complex things less complicated to the users.
- Progressive disclosure is about revealing complexity gradually, when it is relevant to the user. It improves learnability, efficiency and error rates. The system keeps its complexity, but the pace at which it is introduced is carefully designed. This is typically what you see in video games tutorials, or in an digital product onboarding that ends by pointing you to a “see all settings” shortcut, where advanced users will be able to customize their toolbar with tools that may be too much for beginners.
- Scaffolding goes further by providing temporary support that adapts to the user’s current skill level, then progressively withdrawing as their mastery develops. Templates library you see in Notion or Miro are examples of scaffolding: you start with them to see what the tool can do, and then grow confidence to craft your own system.
- Chunking structures complex information into meaningful units that can be processed without impacting the user’s cognitive load. Imagine entering a 20 steps funnel to buy a house: the horror. To make it less scary and manageable, you can arrange the same steps into 4 chapters like
- Your borrowing capacity
- Your applying file
- The offer
- The purchase agreeement
These patterns (and maybe others) help make the experience more accessible without dumbing it down. I truly believe we should embrace helping users grow their mastery rather than not assuming “users don’t read”. If we make them care about what they do, they will. And that’s a better outcome than an interface so smooth it leaves nothing to learn.