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. “Our product is getting too complex,” 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. coming soon “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. does this work the same way it did over there? does this work the same way it did over there? 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. verbs add confirm undo where next 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. Workspace project account 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? 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. Decide what Add looks like and use it twice this week. Add Standardise Confirm and Undo; ship them into three places where people currently hesitate. Confirm Undo Rename one object everywhere and delete the synonyms. No more workspace/hub/dashboard roulette. workspace/hub/dashboard 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. Because it was never really complex. It was unpredictability. And unpredictability, thank fuck, is fixable.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Every

Why SaaS Pricing Pages Fail 

Work

UX\UX Agency London

Read My Stories

UI/UX Design Services

Digital Product Design Services

Free Discovery Call with Me

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Your Product Feels Complex? Give It a Spine

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Why SaaS Pricing Pages Fail

I Built a Product with a No-Code Tool and Pitched it to VCs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Top Industries To Be Transformed By Artificial Intelligence, Soon

10 Tips for Building a Successful MVP with Flutter

Why SaaS Pricing Pages Fail

I Built a Product with a No-Code Tool and Pitched it to VCs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Top Industries To Be Transformed By Artificial Intelligence, Soon

10 Tips for Building a Successful MVP with Flutter

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps