Near Enough Isn't Good Enough: The Gap Between Design and Built
On sweating the details that nobody sees but everybody feels
I’ve been doing a lot of visual QA lately. Comparing coded screens against Figma designs, screen by screen, component by component. And because we’re working within a mature design system — tokens, styles, components all locked in — you’d think the margin for error would be slim.
It is. Which means my feedback has become almost entirely about the small stuff.
Wrong spacing token. Wrong heading style. Wrong text colour. Repeat.
It’s laborious. It’s tedious. And honestly, it gets under everyone’s skin after a while, mine included. But it’s also what got me thinking more carefully about a question I suspect a lot of designers quietly wrestle with: does this level of detail actually matter, or am I just being too picky?
The Three Camps
In my experience, designers tend to fall into one of three camps when it comes to implementation detail.
There are those who sweat every pixel. Those who are comfortable with “near enough.” And those who, under pressure from engineering or product, eventually concede and move on.
The “near enough” camp often takes a dim view of the first group. I’ve heard the phrase “stop pixel pushing” more times than I care to remember, and I’ll be honest, I’ve never liked it. It dismisses the craft without engaging with it. In my observation, this perspective tends to come from designers who didn’t come up through typography or graphic design, and for whom the visual layer feels less critical than the interaction layer. Neither is wrong as a priority, but both matter.
The responsive argument, “it’s fluid, so it’ll never be pixel-perfect anyway,” has some truth to it. But it’s also sometimes used as a reason to stop caring. Vertical spacing, for instance, can be precisely defined and consistently implemented regardless of viewport width. The responsiveness of a layout doesn’t dissolve the responsibility for getting it right.
As for those who concede to pressure: I get it. I’ve been there, and I’ll be there again. But ideally not without at least making the case first.
So Why Does It Matter?
Here’s how I think about it.
Polish is felt, not always seen. When details are off, inconsistent spacing, a heading that’s one weight too light, users don’t typically open a support ticket about it. But I believe they feel it. Something is slightly off, and over time that feeling accumulates. When a competitor’s app eventually “just feels better,” nobody can quite say why. I can say why. It’s because someone, somewhere, stopped sweating the details.
The design deserves to ship as designed. Every decision in a high-fidelity design has a reason behind it. User research, established principles, pattern libraries, hard-won experience. When those decisions get diluted in implementation, it’s not just a visual inconsistency. It’s the work being only half-respected. And after weeks or months of craft, that stings.
This is what separates good product teams from average ones. Attention to implementation detail is one of the clearest signals of a mature design culture. It’s the difference between a product that looks designed and one that is designed.
There’s nothing wrong with pride in your work. You won’t always achieve perfection. The constraints of real projects make sure of that. But there’s value in aiming for it, and a culture that’s given up on trying tends to slide further than it expects.
A Word on Pragmatism
I’d be doing this argument a disservice if I didn’t acknowledge the other side.
Timelines are real. Engineering capacity is finite. There are moments when something genuinely has to ship before it’s exactly right, and that’s a reasonable call to make. What isn’t reasonable is making that call and then forgetting about it.
My approach: if we can’t fix it now, it goes in the backlog. And I’ll keep mentioning that ticket until it gets prioritised. That’s not stubbornness. That’s just doing the job properly.
The detail is the design. It’s also, ultimately, what we’re all being paid to care about.
Opinions are my own and do not represent my employer.
If this resonated, subscribe for more on the parts of design work nobody talks about.