Killing Your Darlings: The Hardest Skill in Design
Sometimes the best design is the one you don’t ship, learning when to push and when to step back.

I changed a design I liked today. Not because it was bad. But because it wasn’t the right call yet.
We need to talk about the hardest skill in design. It isn’t Figma. It isn’t auto-layout. It isn’t color theory.
It’s the ability to kill your darlings.
Early in my career, I thought good design meant defending your ideas. I thought that if I let an engineer or a PM talk me out of a feature, I was failing the user. I was “weak.”
Experience teaches you something else entirely:
Knowing when to push.
And knowing when to step back for the team.
Here is exactly what happened.
The “Perfect” Feature
I’m currently working on a side project with some friends called Showup. It’s a mobility experiment trying to make booking buses less of a headache.
I designed a flow where users could see specific driver details while selecting their bus.
I loved it. It felt reassuring. It felt thoughtful. It added that layer of “humanity” we always talk about in design threads on X (Twitter).
On Figma, it was a perfect design. But my team pushed back.
The Friction Trap
They didn’t care about the aesthetics. They cared about the experiment.
We are in the early stages. The goal isn’t to build a “perfect app.” The goal is to test a hypothesis: Will people book this way?
Based on their experience with real-world usage, my “thoughtful” feature was actually a roadblock.
More information.
More decisions.
More hesitation.
In a vacuum, knowing the driver is nice. In a high-speed booking context? It’s a distraction.
Suddenly, the user isn’t asking. What time does the bus leave? They are asking Is a 4.8-star driver better than a 4.7-star driver?
Protecting the Experiment
This is where the Designer Ego inside me wanted to argue. I wanted to fight for the User Experience because we are the users’ voice.
But then it clicked.
They weren’t attacking the design. They were protecting the experiment.
So I let go of my personal taste. Not because I was wrong. But because the goal wasn’t to ship my idea.
The goal was to run a cleaner test.
Nothing is Permanent
There is a trap we fall into where we treat software like architecture. We act as if once the code is shipped, it is poured in concrete.
If I don’t ship this now, it will never exist.
But here’s the part I find most interesting: Software is soft.
If the data tells us users need that information later? We can add it back. With evidence. With confidence.
Good designers don’t cling to solutions. They make room for learning.
One last thing..., Where have you chosen judgment over preference recently? Reply to this email and let me know. I read every response.
