In 2002, I was a few weeks into a new role, my second since completing my degree two years earlier. I was a frontend engineer at AKQA, a creative agency in London. I’d just finished one of my first projects, building out a new page for a client, and I thought it looked great. So I told the designer it was done.
A while later, I heard him in the engineering room. Den? Where’s Den? He came over to my desk and opened Photoshop. He placed a screenshot of my build on one layer and his original design on another, dropped the opacity to 50%, and let me see the difference for myself.
Everything was off. Spacing, alignment, type rendering, visual weight. Not by miles, but by enough. Enough that the thing I’d built felt different from the thing he’d designed, even though I’d have sworn they were identical.
I was embarrassed. I was so sure it was done.
Something rewired in my brain that day. Not a new skill, exactly, but a new way of seeing. I had started to become an engineer who could see what I’d built through the eyes of the designer, not just through my own.
The gap between what designers intend and what engineers ship is one of the oldest problems in our industry, and it has defined my career since that day. I’ve come to believe it’s the most undervalued skill in software engineering.
The gap is real, and it’s everywhere
Brian Lovin, currently at Notion, wrote recently about the difficulty of hiring what he called “design-minded frontend engineers.” The struggle he describes is widely shared. There are engineers who can code, and there are designers who can design, but the engineers who can honor design intent while building the real product? That pool is vanishingly small.
Lovin’s framing was about frontend engineers specifically, but the gap he’s describing isn’t a web problem; it’s a general UI problem. Mobile engineers ship apps that drift from their designs. Embedded engineers build interfaces for cars, appliances, ATMs, point-of-sale terminals, and medical devices where a misjudged tap target has real-world consequences. Anywhere a human touches software, someone has to close the space between what was designed and what gets built, and that someone is an engineer regardless of what platform they work on.
What’s striking about this gap is how much has been written about it already, and how little has changed. Designers have been naming the problem for years: posts about engineers breaking their designs, articles about the handoff process, and conference talks about the collaboration breakdown. The designer’s perspective on this is a well-established literature. But that literature is written by designers, for designers, and no amount of designers talking to each other about the problem has fixed it, because fixing it was never something designers could do alone. The engineer is the other half of the conversation, and the engineer is the half that has to change.
And here’s the thing: this isn’t a new problem that appeared with the rise of design systems or component libraries. It’s been there since the first time a designer handed a mockup to an engineer and got something back that felt almost right but not quite. The gap between the mockup and the shipped product is an engineering problem, and it’s a problem with a solution. The skills required to close it can be taught.
Defining “design-minded”
The thing to understand about design is that it isn’t the mockup, it’s the experience the person has when they’re using the shipped product. That experience is built by engineers from what designers describe and intend. The mockup is a promise, the feel is what actually ships.
One distinction is the Design Engineer. This is someone who occupies a hybrid role: they design and they build. Matthias Ott has written persuasively about design engineering as the structural fix for the design-implementation gap: a role that holds both disciplines at once and makes the gap stop forming in the first place. Companies like Linear and Vercel have made the role famous, and I’m in awe of the people doing it; they are genuinely talented at both sides.
But it’s also a luxury solution. Most companies can’t hire for it, and even at companies that do, many design engineers typically focus on design systems or high-fidelity components. Somebody still has to take those components and build the actual product with care. Ott’s prescription is a role; mine is a capability. The role is valuable where companies can hire for it, but the capability is what scales to the rest of us.
That somebody is the design-minded engineer. That’s not a new job title; it’s a way of working, of engineering, of caring about how the product looks and feels.
A design-minded engineer is not a designer, and their task is not to originate design decisions but to apply and extrapolate them. The goal is for the designer to look at the shipped product and not be able to tell where their design file ended and the engineer’s judgment began. The highest compliment a design-minded engineer can receive is silence from the designer, because silence means you got it right.
This isn’t about engineers becoming designers either. Designers should still design, and engineers still build. But the engineer who builds with design judgment ships a different product than the engineer who builds without it.
Apply and extrapolate, don’t originate. That’s design-minded engineering.
“The mockup is a promise, the feel is what actually ships”
The framework: three lenses on every design
Over the course of my career, from agency work at AKQA for Nike and Ferrari, to global e-commerce at Volvo, to my accessibility and animation work at Canva, I’ve developed a framework for how engineers should engage with design. It comes down to three lenses:
1. User behavior.
What will people actually do with this? Not what the mockup assumes, but what happens in real conditions. The designer typically designs for one user in one ideal state, while the engineer knows that localized strings reshape layouts in ways the original mockup didn’t account for, that right-to-left languages flip everything, that users will hit this screen on a train with one bar of signal halfway through a checkout flow. The design-minded engineer sees those realities and addresses them before they become bugs.
2. Performance.
What’s the hidden cost the user pays that the mockup can’t show? A prototype can promise buttery smooth interactions, but if the shipped product has 80ms input latency instead of 16ms, users feel the difference even if they can’t articulate it. Samsung famously copied Apple’s pinch-to-zoom gesture, matching the visual design almost exactly, but the interaction felt wrong because the engineering underneath didn’t match the design promise. Performance is a design decision, and engineers are the only ones who can make it real.
3. Accessibility.
Who gets excluded? This is the most defensible concern you can raise in any design review, and it’s the one most often deferred. Accessibility isn’t a compliance checkbox but a signal of engineering quality, and more than that, a signal of care. Passing WCAG scores while the actual screen reader experience is incomprehensible doesn’t count. Turning on VoiceOver and navigating your own product with different input types does.
These three lenses aren’t reasons to block work or push back on designers; they’re the opposite. They’re how an engineer earns a seat at the design table, by caring about design outcomes through a lens that designers recognize and respect.
The engineer as a creative contributor
Design-minded engineering isn’t only analytical, though. There’s a whole dimension that’s about creative contribution.
Engineers know things designers don’t, because the two disciplines have different vantage points. When CSS container queries landed, or view transitions went from spec to stable, or SwiftUI’s animation APIs opened up new motion possibilities on iOS, those weren’t just engineering milestones. They were creative unlocks. Each expanded what was possible in a user interface, and engineers saw the new ground first.
At AKQA, I worked on a Ferrari project not long after CSS got the cubic-bezier() function for custom easing curves. We built a dropdown menu with easing curves derived from actual race car telemetry data. It was the kind of contribution that only happens when an engineer is in the room during the creative conversation, feeding into it, not waiting downstream for a handoff.
The designer is constrained by what they think is possible, and the design-minded engineer knows what actually is. Stay current with new platform capabilities. You’ll have options to bring to every brainstorm, and the team designs something they couldn’t have designed without you.
The undesigned states
If there’s a single idea in this framework that I think resonates most immediately with working engineers, it’s gap states.
Every mockup shows the happy path. The page loaded, the data arrived, the user is logged in, the content fits perfectly. But shipped products have to account for loading states, error states, empty states, skeleton screens, offline fallbacks, optimistic updates, expired sessions, permission denials, locale-specific edge cases, and a dozen other conditions that never appeared in any design file.
These aren’t afterthoughts, they are the product for a significant percentage of real user sessions. The engineer who treats them as first-class design problems, who asks “what does this screen look like with no data?” before leaving the design review, is doing design-minded engineering. The craft applied to these in-between moments is what separates products that feel polished from products that feel like they were built from a mockup and nothing else.
“The highest compliment a design-minded engineer can receive is silence from the designer, because silence means you got it right.”
Sometimes there is no design
Everything I’ve described so far assumes a design exists. But what happens when it doesn’t?
This is where design-minded engineering faces its real exam. Every engineer eventually encounters a situation where they need to build something with incomplete or absent design direction: a feature that needs shipping before the designer can get to it, a prototype built from raw data and business requirements, or a long stretch where the team is between designers.
I’ve lived both extremes. I’ve been handed raw data and asked to build something that felt intentional with no design input at all. And at Volvo, before a design system existed, I spent six months without my designer, building across 70 markets from data and whatever fragments of earlier design work I could find.
The early weeks were the hardest. You don’t realize how much of your confidence comes from having a design to reference until it’s gone. Every decision that would normally take seconds suddenly has weight. What size should this type be? How much padding feels right here? Is this hierarchy clear, or am I just used to looking at it? There’s no mockup to check against, no designer to ask; just you, the data, and whatever design judgment you’ve accumulated over the years.
What I leaned on was the three lenses. User behavior first: what will real people in real markets actually do with this? I knew German strings would be 40% longer than English, that some markets read right to left, that a checkout flow designed for English speakers in a desktop browser would encounter completely different friction points when a user in Saudi Arabia was navigating it in Arabic on a phone. I knew the edge cases because I’d been cataloging them for years. Performance second: what’s the cost of every decision on the devices our users actually have? Not the specced-out MacBook Pro I was developing on, but the mid-range Android in Jakarta, or the spotty connection in rural Norway. Accessibility third: who gets excluded if I get this wrong?
Those lenses didn’t replace the designer, but they gave me a structure for making principled decisions. Instead of guessing what looked good, I was solving for outcomes I could measure or defend. The visual choices I couldn’t reason about, I kept conservative. I matched existing patterns in the system and extrapolated from what the designer had already established rather than inventing something new.
Exercising restraint is the counterintuitive part. When the designer is gone, the temptation is to fill the creative vacuum, to make the bold call, to prove you can do both jobs. But that’s exactly the wrong instinct. The design-minded engineer’s job in that situation is to make the product feel continuous with the designer’s existing intent, not to introduce a new voice. Every time I reached for a decision I wasn’t sure about, I asked myself: if the designer were here, would this surprise them? If the answer was yes, I pulled back and found a more conservative path. Boring is better than wrong when you’re operating without a net.
When the designer eventually returned and reviewed what I’d built, he requested only minor tweaks. Not “what were you thinking?” Just the micro-level adjustments that separate a designer’s instinct from an engineer’s principled approach.
That outcome is the proof of concept for the entire framework. It’s also an honest illustration of where designer instinct is hardest to replicate: the micro-level decisions about spacing, weight, and proportion that feel obvious only after someone with that instinct points them out. Design-minded engineering can get you remarkably close, but recognizing where “close” falls short is part of the skill.
The familiar anti-patterns
Part of developing design fluency is learning to spot where it went wrong. The industry has no shortage of cautionary tales: Snapchat’s 2018 redesign, the hamburger menu epidemic, dark patterns that optimize for conversion while destroying trust, and recently the rise of AI-generated UI that looks plausible and works incoherently.
The hamburger menu is an instructive example, because it felt like such an elegant engineering solution at the time. Screen space is limited on mobile, navigation takes up room, so you collapse it behind an icon. Problem solved. Except the data kept telling the same story: users don’t open menus they can’t see. Features hidden behind hamburger menus saw dramatically lower engagement than features visible in the interface. The space-saving argument won on logic but lost on human behavior, and the design-minded engineer’s contribution in that room wasn’t to have a better opinion about navigation but to notice that the argument for hiding things needed to account for whether users would ever find them again.
“Apply and extrapolate, don’t originate.”
AI makes this urgent
AI is making it easier than ever to generate UI code, and you can prompt your way to a working interface in minutes. That’s exactly why design judgment matters more today than ever.
AI is a powerful tool for design-minded engineers. It can generate locale variants, simulate gap states, produce working prototypes during brainstorms, and catch accessibility issues before the design review. But it can’t evaluate whether the result feels right. It can’t decide whether an animation serves the interaction or just decorates it. It can’t tell you that the loading state your component shows for 200ms on a fast connection will hang for four seconds on a train in rural Portugal.
The risk I see emerging is subtler than “AI will replace designers.” It’s that engineers will start treating AI as a substitute for design judgment. Need a loading state? Ask the model to generate one. Need an error message? Let it write the copy. Need to decide how a component should behave on mobile? Prompt for options and pick the one that looks reasonable. Each individual decision might be fine, but the cumulative effect is an interface that has no point of view, no coherence, no sense that a human being thought carefully about what the person using it actually needs. It’s design by default rather than design by intent.
The design-minded engineer is the counterweight to that drift. They’re the person who looks at the AI-generated output and applies the three lenses: does this serve real user behavior? What’s the performance cost? Who gets left behind? Those questions require human judgment, not better prompts. The execution can be accelerated; the judgment cannot.
Design fluency is a skill, not a talent
I’ve been developing this framework across 25 years in some of the most design-demanding engineering environments in the industry. What I’ve learned is that design fluency isn’t a talent you either have or you don’t. It’s a skill that can be taught, practiced, and developed, and it grows in ways that are hard to see in the moment but obvious in retrospect.
The engineer who starts paying attention to spacing in their first year starts noticing type hierarchy in their third. By year five, they’re catching interaction patterns that don’t match the design intent before the designer does. By year ten, they’re the engineer the designer wants in the room when the hard decisions get made. By year fifteen, they’re the Staff engineer who catches a broken loading state in code review and can articulate exactly why it matters, not just that it looks wrong, but what it does to the user’s trust in the product.
None of that happens overnight, but it starts with a single decision: to care about what you’re building beyond whether it works.
The misalignments I catch now in code review, the edge cases I see before they ship, the interactions I can tell are wrong before anyone else does: none of it would have registered with me in 2002. The AKQA designer with the Photoshop overlay taught me to look. That skill isn’t an innate talent, it’s something any engineer can learn to see for themselves with practice. And the engineers who become design-minded are the ones designers stop having to chase.
