The Call Where It Finally Clicked
Last week, I was on Zoom with a founder who looked completely wrung out. “Our product is getting too complex,” he said, scrolling through screenshots that were… fine. Clean. Sensible. The sort of UI that photographs well. And yet something felt off, the way a tidy room can still feel crowded.
Then he shared a live session. Watching it was like walking through a house where every room obeyed a different set of rules. The kitchen tap turned left, the bathroom tap turned right, and the bedroom had no tap at all, just a sign that said coming soon. That’s when it hit me (again): the problem wasn’t complexity in the mathematical sense. It was personality, predictability, call it the spine of the product. It hadn’t decided who it wanted to be, so users had to treat every door as a guess.
“Too complex” is Often Code For “Too Much Thinking”
When founders say a product is “too complex”, they rarely mean the logic is impossible. They mean users are doing extra mental work just to feel safe. I’ve seen apps with five different ways to create something new. Each path had a respectable rationale; together, they felt like five cousins who’d never met. Analytics told the truth no one wanted to say aloud: 80% of people hugged the flattest, safest path and ignored the clever variations. Not because they lacked ambition—because they didn’t trust the app to behave.
I’ve watched hundreds of raw sessions since, no highlight reels, just real people with fidgety cursors and little sighs. In the good products, people simply try things. They’ve absorbed the product’s personality, so a new screen feels like an old friend. In the wobbly ones, there’s always a pause: does this work the same way it did over there? That split‑second hesitation is expensive. It breaks momentum. It teaches caution. It turns progress into paperwork.
Design The Verbs, Not Just The Features
My first proper breakthrough came on a fintech build. We had a pristine visual system - consistent buttons, tidy forms, everything on brand. The interactions, however, were chaotic. Transferring money between your own accounts felt nothing like paying someone else. Recurring confirmations bore no resemblance to one‑offs. Users second‑guessed every move.
We didn’t fix it with another component. We fixed it by designing verbs. How does add work here? How does confirm work? How does undo work? What’s the rule for where next after success? Once those patterns were real, repeatable, and frankly a bit boring, everything clicked. New features stopped being puzzles and started being compositions of familiar moves. Ship speed went up, support cooled off, and the team’s blood pressure came down.
Language Is Part of The Spine (And Yes, We All Mess This Up)
The most embarrassing lesson I learned: we were calling the same object three different names. Workspace during onboarding, project in the nav, and account on billing. Users weren’t confused by capability; they were confused by whether they were looking at one thing in three places or three different things.
Now, every project I run gets a tiny shared vocabulary in the design files and the code comments. One name per concept, written in plain English. It sounds small. It isn’t. Support tickets drop. Onboarding calms down. New team‑mates stop asking “what do we call this again?” and start shipping.
Modularity Is a People Problem Before It’s a Pixels Problem
Here’s the bit I wish someone had told me sooner: giving your product a spine is not just a design exercise. It’s a communication exercise. You need a shared mental model of how the product behaves across design, engineering, product, and support. I sometimes ask teams to describe the product as a person.
Helpful or efficient? Careful or fast? Formal or casual?
The answers are chaotic at first; then they converge. That convergence quietly decides a thousand micro‑choices later. It’s how you avoid shipping “witty” modals next to GDPR‑scented warnings. It’s how you sound like one capable adult rather than four different interns sharing a keyboard.
Start Small, Prove It Quickly (And Yes, Ship Every Day)
You don’t need a Big Redesign™. You need a spine, built one vertebra at a time. Pick one flow that hurts and fix it end‑to‑end.
- Decide what Add looks like and use it twice this week.
- Standardise Confirm and Undo; ship them into three places where people currently hesitate.
- Rename one object everywhere and delete the synonyms. No more workspace/hub/dashboard roulette.
- Pair a designer and a developer for a morning to replace a patchwork of buttons with one component wired to real variants.
Then look at what you already measure: time to first value, clicks to complete, sessions with errors, and support pings per 1,000 users. If those numbers move the right way, do the next flow. If they don’t, own it, adjust, and move again. No committees. No 40‑page doctrine. Just visible, boring consistency that pays for itself.
What Changes When the Product Finds Its Personality
There’s a moment I’ve seen a dozen times now where a product finally feels like itself. Support tickets shift from “how do I…?” to “could it also…?”. Users explore instead of tiptoeing. Internally, design reviews get shorter because there are fewer arbitrary choices to debate. One team I worked with went from spending a third of engineering time on “small UX fixes” (read: inconsistency) to under five percent, not because they stopped caring, but because consistency started doing the quiet work for them.
You’ll notice the tone settles too. Errors become actionable instead of apologetic. Success states offer a door, not a high‑five. Destructive actions are reversible where possible and unmistakable where not. None of that is flashy. All of it breeds trust.
The Blunt Bit (Because Someone Has to Say It)
If your app uses three different words for the same thing, that’s not charm, that’s noise. If your confirm modals work four different ways, that’s not flexibility, that’s you asking users to do QA. And if your fix for every disagreement is “we’ll add a setting”, you’re not empowering anyone, but rather, you’re exporting indecision. Cut the fluffy shit. Pick a rule, explain it once, and let the product teach it everywhere.
Closing: Predictability Feels Like Simplicity
The products I love do complex things without making me feel clever for surviving them. That’s the test. Predictability feels like simplicity because it gives me my attention back.
Give your product a spine. Not a museum‑grade design system, not a manifesto; just a small set of shared flows for the moments that matter, shared words for the things that repeat, and a light, regular handshake between design and code. Do that for a fortnight and watch “too complex” disappear from the conversation.
Because it was never really complex. It was unpredictability. And unpredictability, thank fuck, is fixable.