Early in my career, I designed for myself.
Not intentionally. I genuinely believed I was doing good work. I wanted the most modern solution, the most considered layout, the most current direction. And sometimes clients trusted that. They saw me as the expert and went along with it.
But some pushed back. And when they did, I did not always handle it well. I told myself they were not understanding the vision. What I did not see yet was that the vision was theirs — not mine. I had been commissioned to help bring someone else's idea to life, and somewhere along the way I had made it about what I thought was right.
That friction was the first real lesson empathy taught me.
It did not happen all at once. It was a slow recognition that designing well means getting out of your own head. It means holding space for how someone else sees their product, their users, their idea — even when your instinct pulls you somewhere different. That requires patience. It requires listening past what someone says to understand what they actually mean. And it requires letting go of the need to be validated by the outcome.
That same lesson followed me into team work.
When I think about how designers collaborate with developers, I have seen it go sideways in a familiar way. The posture becomes: design to my spec, it is grounded in research. And yes — the research matters. The craft matters. We should advocate for what the work is telling us. But developers are not order takers. They are gatekeepers in the best sense. They carry knowledge about the platform, about what is actually buildable, about constraints that do not show up in a design file. When we ignore that, we do not just create friction — we leave real value on the table.
Empathy inside a product team is what keeps that from happening. It is what allows a designer to stay principled without becoming rigid. It is what makes tradeoffs feel intentional rather than like something was lost. When people feel heard — when they feel like their contribution shaped the outcome — they invest more. That investment does not always show up in a metric. But it shows up in the quality of what gets built.
The question I keep coming back to is simple: given what we know about the user, what is the best solution we can deliver right now — and what is our plan to build toward the ideal?
I learned to ask that question through friction I created myself. I am still learning how to answer it well.