I recently wrote a piece arguing that designers accept inherited structures too easily. That we fill holes in frames we never questioned, and that real breakthroughs (the car, not the faster horse) come from interrogating the foundation itself.
This article is going to sound like I'm taking it all back. I'm not. These two ideas aren't fighting each other; they're solving two different problems. That one was about where new value comes from. This one is about where your limited energy should go. Hold both, and you get something more useful than either alone. Bear with me.
Engineers have a rule that designers should steal more often: don't solve what's already solved.
It sounds lazy. It's actually one of the smartest defaults in the craft. If you rebuild every solved problem from scratch, you burn most of your energy re-deriving answers the world already has, and the returns on that are close to zero. Nobody is waiting for your bold new take on the back button.
Say I'm building a new app. There is a mountain of things I simply do not need to rethink. How navigation works. How forms behave. Type scale, contrast, spacing, the boring foundations. If I'm building on iOS, Apple has already spent years and absurd amounts of money figuring out how native components should feel. My users' thumbs are already trained. Rejecting all of that to "put my own spin on it" isn't creativity. It's tax. Paid by the user, mostly.
Conventions aren't just efficient for us. They're a kindness to the person using the thing.
A familiar pattern is one less thing they have to learn. Every convention you break is a small withdrawal from their patience, and you'd better be buying something worth more than what you took.
So the rule stands. Don't reinvent the wheel.
Now, back to the tension I opened with. If questioning structures is where breakthroughs live, and reusing structures is where sanity lives, which one do you actually do?
Both. Because they were never answering the same question. "Question the structure" is about escaping frames that quietly limit what you can imagine. "Don't reinvent the wheel" is about not wasting yourself on frames that are genuinely fine. The first protects your vision. The second protects your resources. The trick is knowing which situation you're standing in. And that's not philosophy, it's strategy. The question that decides it is brutally simple:
Is this where my product wins, or not?
Every product has a small core where it's actually trying to be different, the reason it deserves to exist. That's where you interrogate the structure, break patterns if you must, spend your weirdness budget. And around that core sits everything else: login flows, settings screens, list views, standard type. That's where you take the wheel off the shelf, say thank you, and move on.
The failure modes are mirror images of each other.
Reinvent everywhere, and you ship a product that's exhausting to use and late to market, where the actual innovation drowns in a sea of unfamiliar buttons. Reinvent nowhere, and you ship a perfectly conventional product with no reason to exist. A competent arrangement of other people's decisions.
The skill isn't in picking a side. It's in drawing the line consciously. Most teams never draw it at all; they just drift. Designers with taste drift toward reinventing too much, because rethinking things is the fun part. Teams under pressure drift toward reinventing nothing, because shipping is the survival part. Neither drift is a decision.
Here's the test I use now. For any piece of the product, ask: if I made this radically better, would anyone choose us because of it?
If yes, that's your wheel to question. Go deep. Break things.
If no, it's solved. Use the solved version. Gratefully.
Spend your originality where it compounds, and be aggressively unoriginal everywhere else.
Not reinventing the wheel was never an instruction to stop thinking. It's an instruction about where to think.