At a previous company, I sat in a meeting where we were debating whether to redesign a feature that had been in the product for three years. The PM thought we should leave it alone. It works, users know it, so why mess with success? Then someone pulled up the original design spec from 2021. It turns out the feature was built to solve a problem that no longer existed. The vendor API it was working around? Fixed 18 months ago. The technical constraint that shaped the entire interaction was also gone. But users still used it. Not because it was the best solution. They'd just learned how to use what we gave them, and nobody ever went back to ask whether we should rebuild it properly now that we could. That meeting stuck with me. My husband wrote something years ago that kept coming back to me: "If need is the mother of invention, usability should be the father." It's a phrase I've been thinking about a lot lately—how usability keeps transforming products long after the original need is solved, sometimes long after that need has completely changed. wrote something Products keep changing even when they look the same Products keep changing even when they look the same Think about bicycles. The ones we ride today look nothing like the first versions. Those early designs were awkward, uncomfortable, and kind of dangerous, actually. But the core need stayed the same: human-powered transportation. What evolved was our understanding of usability. Better materials, yes, but also refined ergonomics and improved balance. Each generation learned from watching people actually ride these things. Not inventing something new, just making the existing invention more human. I keep seeing this pattern. The first version solves the need. Everything after that? It's about making the solution livable. Why "it works" is a trap Why "it works" is a trap Teams treat "it works" like a finish line. Feature shipped, problem solved, next thing please. But "it works" usually just means users figured out how to accomplish their goal despite the friction. Doesn't mean the friction isn't there. Doesn't mean they wouldn't jump at something better. They've just adapted. I was reviewing a flow a while back in which users had to click through three confirmation screens to complete a single action. Why three confirmations? Nobody on the current team could tell me. We dug through old tickets and found that two years ago, there was a data loss bug. The triple confirmation was a temporary patch while engineering fixed the root cause. They fixed the bug six months later. The three confirmation screens stayed. Because it "worked." Users got through it, drop-off wasn't terrible, and other priorities came up. That's not usability evolving. That's usability getting stuck. What actual evolution looks like What actual evolution looks like Real usability evolution isn't about adding features. It's refinement based on how people actually use what you built. ATMs are probably the clearest example I can think of. First-generation ATMs gave you cash first, then returned your card. Simple, functional, solved the need. But people would grab their cash and walk away, leaving their card in the machine. Later designs reversed the order: card first, then cash. Not a new invention. Not solving a different problem. Just adapting to how humans actually behave instead of how the machine logic suggested they should behave. Same core function, shaped around reality instead of theory. Why do products stop evolving? Why do products stop evolving? From what I've seen, products stop improving their usability for a few predictable reasons. The original designer left, and nobody knows why things work the way they do. Teams get nervous about changing anything. Metrics look fine, so there's no business case. Even though users have just learned to work around problems. The system got so interconnected that changing one thing breaks three others. Small improvements feel too risky. Or the team moved on to new features. Improving what exists feels less exciting than building what's next. All reasonable. Allare  slowly eroding your product's usability. What I've noticed about features that improve vs features that stagnate What I've noticed about features that improve vs features that stagnate The features that keep getting better usually have someone who still cares about them. An owner is watching how people use it, noticing small frustrations, pushing for refinements. Features that stagnate are orphans. Nobody owns them anymore. They work "well enough." Which means they never get better. One team I worked with had this practice they called "adoption reviews." Every quarter, they'd look at features that launched more than six months ago and ask: how are people actually using this now? Not just "are they using it" but how. What workarounds did they develop? What's harder than it needs to be? What did we learn since we built it? Then they'd prioritize improvements based on real usage patterns, not just new feature requests. Not exciting work. But it's the difference between products that age well and products that just get old. When evolution goes wrong When evolution goes wrong Sometimes teams overcorrect. They see users struggling and immediately redesign without understanding why it works the way it does. I watched a team simplify what seemed like an unnecessarily complex flow. Three steps became one. Much cleaner. Everyone on the team was excited. Drop-off rates tripled. Those three steps weren't random complexity. They were scaffolds that helped users make better decisions. Collapsing everything into one screen removed the structure people needed to think through their choices. Good evolution requires understanding not just what people do, but why the current design works, even when it seems like it shouldn't. The products that never stop improving The products that never stop improving The products I actually love using don't necessarily have the best features. They have the best evolution. Google Search hasn't changed its fundamental purpose in 20 years. But the usability keeps evolving. Autocomplete, instant results, knowledge panels, and featured snippets. Each one is based on learning how people actually search, not how Google thought they would search. Slack didn't invent team chat. They just kept refining how it works. Threading, reactions, better notifications, smarter search. Small improvements that add up over time. These aren't dramatic reinventions. They're careful, continuous evolution based on watching real people use the product. What this means for how I think about design now What this means for how I think about design now Need might create the first version of your product. But usability evolution determines whether there's a tenth version. The questions I ask myself now are different from those I used to ask. What are we keeping just because it exists, not because it's still right? What constraints shaped our design that don't apply anymore? What have users learned to work around that we could actually fix? And probably the most important question: who on the team is responsible for making existing features better, not just building new ones? Something worth trying Something worth trying Every few months, pick one established feature and pretend you're designing it fresh today. With current technology, current understanding of users, and current business context. Would you design it the same way? Usually, the answer is no. And when it is, the next question is: what's stopping you from making it better? Sometimes it's real constraints. But a lot of times it's just inertia. And inertia is expensive when you're competing with teams that actually evolve their products. Where I've landed on this Where I've landed on this Need invents products. Usability determines whether those products stay relevant. The invention gets you to market. The evolution keeps you there. Teams that get this don't just ship and move on. They ship, watch what actually happens, learn from it, and refine. Continuously. Even when things seem to be working. Especially when things are working, actually. Because "working" is just the starting point for what a product can become. Because "working" is just the starting point for what a product can become. Because "working" is just the starting point for what a product can become.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

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

Why “It Works” Is Often the Most Dangerous Phrase in Product Design

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

The Design Documentation No One Asks For (But Everyone Needs)

When "Good Enough" UX Becomes the Most Expensive Decision You'll Ever Make

The Design Documentation No One Asks For (But Everyone Needs)

Code, No-Code, or AI Prompt? Exploring the New Debate

14 Must-Have UX Tools for Designers

14 Habits Of The Growth Hacker Mindset: A Deep Dive

The Design Documentation No One Asks For (But Everyone Needs)

When "Good Enough" UX Becomes the Most Expensive Decision You'll Ever Make

The Design Documentation No One Asks For (But Everyone Needs)

Code, No-Code, or AI Prompt? Exploring the New Debate

14 Must-Have UX Tools for Designers

14 Habits Of The Growth Hacker Mindset: A Deep Dive

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps