It’s easy to assume you understand how things like zippers, bikes, and door handles work, until you are actually challenged to describe how they work.
The Illusion of Explanatory Depth is a study by Rozenblit and Keil that shows most people overestimate their understanding of how things work. You can imagine this problem in your own teams. So I wrote about it.
This had me cracking up…
In a design context, this explains a lot of the struggle teams have in finding alignment!
Cooooonstant struggle. In myself and recognizing mis-alignment in others. Hard not to become pedantic and over-explain.
haha, this is good! It’s also exposes such an emphasis on how our brains function so differently person to person.
Haha, and yes, our brains think differently. Skills matter, but observing isn’t a skill everyone has… “did you even try” 
Seems like these people just don’t know how bikes work 
to be fair, I used to love everything about gears, chains, and other nerdy systems so I’d probably have an unfair advantage
I think this is where it gets interesting, especially for decision making in design, which mixes thinking styles.
Dual-process theory is another way to think about this problem. We think using two different modes of cognition. The core idea is that the mind operates with a fast, intuitive system and a slower, more deliberate system.
So i guess if the fast thinking is operating in the wrong environment, all kinds of problems can start to emerge.
Fast and automatic
Slow and deliberate
This is a good way to explain why teams feel aligned until they have to explain tradeoffs, user behavior, or causality. This is where UX metrics and collecting design signals can help us push through the difficulty of slow and deliberate thinking.
Been thinking more about why teams gravitate toward answers that feel familiar and agreeable, even when the ideas themselves are not very good.
Is it just me, or does it feel like people are more likely to choose the comfortable path now?
I know familiarity feels like understanding because it reduces mental effort. When we recognize words or concepts we have seen before, we treat that recognition as comprehension. It feels easy and safe, so the brain rewards it with confidence.
I also think many teams are trying to avoid conflict.
Familiar language creates a sense of belonging. Questioning it introduces friction, so teams often opt for comfort over working toward shared clarity. It’s why so many decisions feel solid at first, then fall apart when teams have to explain tradeoffs, user behavior, or outcomes. The agreements are solid, but often very shallow.
I think this is where UX metrics help. They make it easier to break these patterns by moving teams from simply recognizing user issues to actually reasoning through what to do about them. They also slow teams down just enough to think more clearly.
I know familiarity feels like understanding because it reduces mental effort. When we recognize words or concepts we have seen before, we treat that recognition as comprehension. It feels easy and safe, so the brain rewards it with confidence.
Well put. The trap is often the difference in posture when starting the task. Do we just take it on as an order because of familiar language, or do we always take on tasks from the posture of deliberation.
I think this comes down to the culture we create and the rituals and patterns the team adopts. Having an experimental mindset is one thing, but having a team that encourages you to stretch an idea or concept beyond a task makes it happen regularly. There’s social reinforcement.
@byhuber speaks to this in his thread on experimentation.
Upon rewriting this comment, I think I agree. In my experience, large organizations often operate like smaller startups from the perspective of ‘we need you to design this’ requests being passed from one silo of expertise to another.
We become open to experimentation when there is a mutual agreement that there are things to learn. If the C-suite, engineering, or a distribution of pieces of the business expect design to ‘make for us this established thing’, asking to experiment feels like incompetence or delay.
Most of the tension shows up when the ask lives in execution, but the expectation sounds like strategy. A stakeholder wants something impressive, differentiated, or bold, while the underlying brief assumes the direction is already set.
The effort gets underestimated (feels “familiar and understood”), and design is left holding the gap.
This is rarely a failure of strategy at the top, from my experience.
I’ve found it’s more often a mismatch between what the work actually is and what people hope it will accomplish. Execution work cannot deliver strategic change, no matter how polished it looks.
When designers do step into strategic thinking, they can’t stop at design framing. They have to bring business judgment with them. That means explaining tradeoffs, cost, risk, and impact in terms that the stakeholder already uses.
A strategic approach only works when it shapes direction in business terms, not just design intent.
Building on this thread, here are two posts that both poke at the role of speed. “Familiar” is often good enough when you win on speed.
There’s now a compression between intent and execution. AI shrinks the distance between “I want this” and “it exists.” Anything that adds delay, abstraction, or ceremony inside that gap starts to feel wasteful. Familiarity works in many cases because AI fills in the execution gaps. You do not need to understand how the bike works to ride it.
AI is collapsing the value of traditional software interfaces, turning prompts into products. When anyone can generate a custom interface in minutes, the moat shifts away from UI and features toward things AI cannot easily replace, like data, trust, and networks (hello Glare!)
→ AI is the new UI. And it’s why software as a business is dying.
The market has largely caught up to standardized interfaces. A visually branded experience is no longer the differentiator it once was. The experience itself matters more.
It might look like the value of execution has dropped, but what’s really happening is a rise in familiarity without understanding. In many cases, understanding is optional. AI can do the work.
The risk shows up as stakes rise. You can see the same pressure hitting professional services.
Companies want immediate execution under short-term pressure. They may be cutting agencies not because strategy is useless, but because long discovery phases and decks do not relieve the pressure they are under.
“The agencies that survive will remove work and deliver results fast, not sell thinking or presentations.”
That has always been true. AI is just accelerating it. People do not want to pay for familiar.
What is actually happening:
That is why speed makes things worse (before it makes them better?)
Speed exposes:
The key will be having the ability to execute using clear thinking and effective understanding of AI. No doubt there are big gains to be made on the engineering side:
But where does innovation happen? Once you’ve rebuilt the thing using an existing API, who is creating new end points for new features? Once the engineering team has accelerated production, how does the whole team take the 50% project time they saved and put 10% more into rigorous design thinking that creates a more cohesive system?
Just some thoughts to push this along.
Agreed. Teams are going to confuse executing faster in iterations with actual experiments and strategy.
This already happens, but it will be more pronounced.
@schuboxaz you’re iterating on new features and patterns with AI all the time. Can you speak to the struggle of pushing past the existing components and boiler-plate design patterns?
and to this, I’d ask.. how do you distinguishing between iteration and experimentation?
Love this. I think a post on this is helpful.
Iteration is about improving something you already believe is directionally right.
What we are trying to do is tune, refine, or optimize within known constraints. “Can we make this work better?”
Iteration is about outputs… more design work, better flows, tighter UI.
Experimentation on the other hand is about testing whether the direction is right at all.
You are intentionally reducing uncertainty around a particular decision. “Should this exist, and if so, why?”
Experimentation produces a decision… it is ideation with consequences.
This is a great topic for our concepts @MoData and @EricZ
I think there are three mental models or approaches to think about these ideas:
Love the distinction here @Bryan and I agree I think this could be a meaty post. I often see the words used interchangeably, when perhaps they shouldn’t be. In practice, they have very different intents. Which shapes the experience, love this POV, ty!!
