I was in a Zoom call last week with a founder who looked genuinely defeated. "Our product is getting too complex," he said, pulling up screenshot after screenshot of interfaces that all looked... fine? Good, even. But something was off.
Then he showed me how users actually moved through the app. It was like watching someone navigate a house where every room had different rules. The kitchen worked one way, the bedroom another, and the bathroom might as well have been from a different house entirely.
That's when I realized: this isn't about complexity. It's about personality. His product didn't know what it wanted to be.
The Lie We Tell Ourselves About Complexity
Here's the thing that took me years to figure out: when founders say "our product is too complex," they're almost never talking about the actual functionality. They're talking about cognitive load.
I've seen this pattern dozens of times now. The product can do amazing things, but using it feels like constantly having to relearn how to drive every time you get in a different car.
Last month, I was working with a team whose app had five different ways to create something new. Five. Each one made perfect sense in isolation—the designer could walk me through the reasoning for every choice. But for users? It was like the app had multiple personality disorder.
The real kicker? When we dug into their analytics, 80% of users were only using the most basic version of each feature. All that careful customization, all those edge cases they'd designed for—mostly ignored. Because people couldn't predict how the app would behave, so they stuck to the safest, most obvious path.
What I Learned from Watching 100+ User Sessions
I started obsessively watching user session recordings a couple years ago. Not the highlight reels from usability tests, but raw footage of people actually trying to get work done.
The pattern was always the same: Users would learn how to do something in one part of the app, then encounter a similar task elsewhere and... pause. You could see them thinking, "Wait, does this work the same way it did over there?"
That hesitation kills momentum. It breaks trust. Users start feeling like they need to be careful, like they might break something or miss something important if they don't pay attention to every detail.
But in the apps that felt effortless? Users would encounter something new and just... try it. Because they'd unconsciously learned the app's personality. They knew how it would behave.
The Modularity Revelation That Changed Everything
I used to think modularity was about efficiency—reusing components to ship faster. That's true, but it misses the bigger point.
Real modularity is about creating a shared language between your product and your users. When someone learns how to delete something in one context, they should be able to delete anything, anywhere, with confidence.
I learned this the hard way working on a fintech app a few years back. We had this beautiful, consistent visual design system. Every button looked identical, every form followed the same layout principles. But the interactions? Chaos.
Transferring money between your own accounts worked completely differently from paying someone else. The confirmation flow for recurring payments bore no resemblance to one-time payments. Users were constantly second-guessing themselves: "Am I in the right place? Is this going to work the way I expect?"
The breakthrough came when we stopped designing features and started designing verbs. How does "transfer" work? How does "confirm" work? How does "undo" work?
Once we nailed those interaction patterns, everything clicked. New features became compositions of familiar moves instead of novel experiences requiring new mental models.
The Invisible Patterns Users Crave
Here's what I notice when I watch users interact with well-structured products: they develop muscle memory not just for where things are, but for how things behave.
They learn that error messages in this app are always actionable, never just apologetic. They discover that when they're about to do something potentially destructive, the app will always give them a clear way out. They internalize that "save" means "save and stay here" while "save and continue" means exactly that.
These aren't features. They're promises your product makes to users about how it will behave. And the magic happens when users start trusting those promises.
I remember working with one team that was getting crushed by support tickets. Users constantly asking how to do things that should have been obvious. We spent weeks analyzing the requests, looking for patterns.
The insight wasn't what we expected. It wasn't that any individual flow was broken. It was that users had learned not to trust their instincts about how the app worked. They'd been burned too many times by inconsistent behavior, so they'd stopped assuming anything.
Language is Everything (And We're All Terrible at It)
One of the most embarrassing realizations of my career: I was calling the same concept by different names throughout an entire product. In onboarding, we talked about "workspaces." In the main nav, they were "projects." In the billing section, somehow they'd become "accounts."
Users weren't confused about the functionality. They were confused about whether they were looking at three different things or the same thing in three different contexts.
Now I obsess over this stuff. I keep a shared vocabulary document for every project—not buried in some wiki, but right in the design files and the codebase comments. When someone suggests a new term for an existing concept, we have a conversation about whether it's actually better or just... different.
The ripple effects of consistent language are insane. Support tickets drop. Onboarding becomes self-explanatory. New team members can understand the product faster because the concepts have stable names.
How Teams Actually Break Things
I've seen the same pattern kill modularity efforts over and over: someone builds a great pattern, it works beautifully in one context, then gets copy-pasted into a slightly different context where it doesn't quite fit.
Instead of adapting the pattern thoughtfully, they just... tweak it. A little. Just for this one case.
Six months later, you have seven variations of the same interaction, each one slightly different, none of them clearly better than the others. Users can't develop muscle memory because the muscle memory keeps getting invalidated.
The solution isn't to be rigid about never adapting patterns. It's to be intentional about when and why you break consistency. If you're going to do something different, make it obviously different, not subtly different.
What Changes When You Get the Personality Right
There's this moment—I've seen it happen maybe a dozen times now—when a product finds its personality. User behavior completely changes.
Support tickets shift from "how do I do this?" to "can you add this feature?" Users start exploring instead of tiptoeing. They begin to trust their instincts about how things will work.
But the most telling change? The internal conversations. Product discussions stop being about micro-interactions and start being about capabilities. Design reviews become faster because there are fewer arbitrary choices to debate.
I worked with one team that went from spending 30% of their engineering cycles on "small UX improvements" (translation: fixing inconsistencies) to maybe 5%. That's not because they stopped caring about user experience. It's because they'd front-loaded the consistency work, so new features just... worked predictably.
The Thing No One Talks About
Here's what I wish someone had told me five years ago: giving your product a consistent personality isn't a design problem. It's a communication problem.
The best design system in the world won't help if your team doesn't have shared mental models about how the product should behave. You need to get everyone—designers, developers, PMs, even support people—aligned on the personality you're building.
I've started doing these weird little exercises with teams. I'll ask everyone to describe the product as if it were a person. Is it helpful or efficient? Careful or fast? Formal or casual?
The answers are always all over the place initially. But by the end of the conversation, we usually land on something everyone can rally around. And that becomes the north star for all the micro-decisions that actually determine how the product feels.
Starting Small (But Starting Right)
Every time I suggest this approach, someone asks: "But where do we start? We can't rebuild everything."
You don't need to. Pick the one user flow that's causing the most confusion right now. Make that flow work consistently from start to finish. Get everyone on the team to use the same words for the same things in that flow.
Then watch what happens. Users will start completing that flow faster. Support tickets about that area will drop. And—this is the part that hooks teams—building new features in that area becomes easier because you have established patterns to compose from.
I've seen teams transform their entire product by fixing one flow at a time. It takes longer than a big redesign project, but it's also way less risky and way more sustainable.
The goal isn't perfection. It's predictability. And predictability, it turns out, feels like simplicity to users—even when you're doing complicated things.
What This Really Means
The products I love using don't feel simple because they do simple things. They feel simple because they do complex things in ways that make sense to me.
That's not about visual design or information architecture or any of the stuff we usually focus on. It's about behavioral consistency. It's about your product having a clear personality that users can learn to predict and trust.
Most products I encounter feel like they were designed by committee—not because too many people were involved, but because those people never aligned on what personality they were building.
Give your product a spine. Not a design system, not a style guide, but a clear sense of how it behaves in the moments that matter to users.
Do that, and the word "complex" just... disappears from conversations. Because complexity was never the real problem. The problem was unpredictability. And unpredictability is absolutely fixable.
Top comments (0)