The invisible gap between what designers create and what engineers finally ship

In 2002, only a few weeks after starting a new role, I had one of the most formative moments of my career.

It was my second job after university, and I was working as a frontend engineer at AKQA, a creative agency in London. I had just wrapped up one of my early tasks: building a new page for a client. I thought it looked excellent. Confidently, I told the designer it was finished.

A while later, I heard him calling through the engineering room.

Den? Where’s Den?

He walked over to my desk, opened Photoshop, and placed my implementation on one layer and his original mockup on another. Then he reduced the opacity.

The difference was immediate.

Spacing was slightly off. Alignment drifted. Typography rendered differently. Visual balance felt uneven. None of the mistakes were dramatic, but together they changed the feel of the page entirely.

I had genuinely believed the two versions matched.

That moment permanently changed how I approached engineering. It wasn’t simply about learning another technical skill. It was about developing a different way of seeing: learning to view what I built through the eyes of the designer rather than only through my own perspective.

Since then, I’ve become convinced that the gap between design intent and shipped software is one of the most persistent and undervalued problems in software engineering.

---

The gap exists everywhere

Recently, Brian Lovin from Notion wrote about the difficulty of hiring what he described as “design-minded frontend engineers.”

The issue he described is familiar across the industry.

There are engineers who can build products. There are designers who can create interfaces. But engineers who can preserve design intent while translating it into a real product? That group is remarkably small.

Although Lovin focused on frontend engineering, the problem goes far beyond the web.

Mobile apps drift away from their original designs. Embedded systems in vehicles, ATMs, medical devices, and payment terminals often lose fidelity between concept and implementation. Anywhere software interacts with humans, engineers are responsible for narrowing the distance between what was imagined and what users eventually experience.

What makes this especially interesting is how long the industry has discussed it without solving it.

Designers have written extensively about:

• engineers damaging designs during implementation,
• problems in the handoff process,
• collaboration failures between design and engineering teams.

But most of that discussion has existed within design circles.

The reality is that designers alone cannot fix this problem because engineers are the ones who ultimately transform intention into software.

And this issue didn’t suddenly appear alongside design systems or component libraries. It has existed since the first time a designer handed over a mockup and received back something that looked almost right but somehow still felt wrong.

The important thing is that this is not an unsolvable problem. The ability to close that gap can absolutely be learned.

---

What “design-minded” really means

Design is not the mockup itself.

Design is the experience users have when interacting with the final shipped product.

Engineers are the people who transform a designer’s intent into that experience. The mockup is simply the promise; the feeling users experience is what actually matters.

One approach to solving the gap is the Design Engineer role.

This is someone who both designs and builds.

Matthias Ott has written convincingly about design engineering as a structural solution to the implementation gap. Companies like Linear and Vercel helped popularize the role, and the people doing this work are genuinely exceptional.

But it’s also an expensive solution that many companies cannot realistically scale.

Even organizations with design engineers still need regular engineers who can implement products carefully and thoughtfully.

Ott’s idea describes a role. What I’m describing is a capability.

Think of it as a more accessible version of design engineering: the version available to every engineer building user-facing software.

That person is the design-minded engineer.

It’s not a special title. It’s a mindset. A way of building software with sensitivity toward how the product looks, behaves, and feels.

A design-minded engineer is not trying to become a designer. Their job is not to invent design decisions from scratch.

Their role is to apply existing design decisions and intelligently extrapolate from them.

The ideal outcome is simple:

The designer should look at the final product and struggle to identify where the design file ended and the engineer’s judgment began.

The greatest compliment such an engineer can receive is silence from the designer. Because silence means the implementation respected the intent perfectly.

This is not about merging two professions together. Designers still design. Engineers still engineer.

But engineers who build with design judgment inevitably ship different products than engineers who do not.

Apply and extrapolate. Don’t originate.

That is design-minded engineering.

“The mockup is a promise. The feeling is what actually ships.”

Three lenses for evaluating every design

Across my career, from agency work at AKQA for Nike and Ferrari, to global commerce systems at Volvo, to accessibility and animation work at Canva, I gradually developed a framework for how engineers should engage with design.

Everything comes down to three lenses.

1. User behavior

What will people actually do with this?

Not in ideal conditions. Not in the perfectly staged scenario from the mockup. But in reality.

Designers usually work around a single ideal state. Engineers deal with the messy world beyond it.

Localized strings reshape layouts. Right-to-left languages invert interfaces. Users interact with products on unstable connections, outdated devices, crowded trains, and stressful checkout flows.

The design-minded engineer anticipates those realities before they become production bugs.

2. Performance

What hidden cost does the user pay that the mockup cannot reveal?

A prototype can suggest silky smooth interactions, but if the shipped version introduces 80ms latency instead of 16ms, users feel the difference immediately even if they cannot explain why.

Samsung once reproduced Apple’s pinch-to-zoom interaction almost visually perfectly. But the interaction still felt wrong because the engineering beneath it failed to preserve the intended experience.

Performance is a design decision. And engineers are the ones responsible for making it real.

3. Accessibility

Who gets excluded?

Accessibility is often treated as compliance work when it should really be viewed as a signal of engineering quality and care.

Passing WCAG checks means little if the actual screen-reader experience is unusable.

Turning on VoiceOver and navigating your own product properly matters far more.

These three lenses are not weapons for blocking work or fighting designers. They are the way engineers earn credibility in design conversations.

They show that the engineer genuinely cares about the final user experience.

---

Engineers are creative contributors too

Design-minded engineering is not purely analytical. It also includes creative contribution.

Engineers often understand possibilities that designers haven’t yet seen.

When CSS container queries arrived, when view transitions stabilized, or when SwiftUI animation APIs unlocked new interaction patterns on iOS, those were not just technical milestones.

They expanded the creative possibilities of interfaces.

At AKQA, shortly after CSS introduced cubic-bezier() easing curves, I worked on a Ferrari project where we built animation timing curves based on real race car telemetry data.

That type of idea only emerges when engineers participate in the creative process itself rather than waiting downstream for design handoff.

Designers are constrained by what they believe platforms can do. Design-minded engineers understand what platforms can actually do.

Staying current with platform capabilities changes the creative ceiling of the entire team.

---

The states nobody designed

One of the most practical ideas in this framework is the idea of gap states.

Mockups usually show the happy path.

The page loads correctly. The data arrives. The user is authenticated. Everything fits perfectly.

Real products do not live in ideal states.

They require:

• loading states,
• error states,
• empty states,
• offline fallbacks,
• optimistic updates,
• expired sessions,
• permission failures,
• localization edge cases,
• skeleton screens.

These are not secondary concerns. For many users, these states are the actual product experience.

The engineer who asks “what does this screen look like with no data?” before leaving a design review is practicing design-minded engineering.

The care applied to these transitional moments often determines whether a product feels polished or unfinished.

“The highest compliment a design-minded engineer can receive is silence from the designer.”

Sometimes there is no design at all

Everything so far assumes a design exists.

But eventually every engineer encounters situations where there is little or no design guidance:

• a feature must ship before design resources are available,
• a prototype must be built from raw requirements,
• a team temporarily has no designer.

I’ve experienced both extremes.

I’ve been handed raw business requirements and asked to build something intentional without any design input.

At Volvo, before a formal design system existed, I spent six months building experiences across 70 markets largely without direct design support.

The first weeks were difficult.

Without a design reference, every tiny decision suddenly becomes heavier.

What font size feels right? How much spacing should exist here? Is this hierarchy genuinely clear or merely familiar because I’ve stared at it too long?

There is no mockup to compare against. No designer to consult. Only accumulated judgment.

The three lenses became my anchor.

User behavior came first. What would people across different markets actually experience?

German text expands layouts. Arabic changes reading direction. A desktop checkout flow behaves very differently on mobile devices in Saudi Arabia.

Performance came second. What devices are real users actually holding? Not the high-end development machine on my desk, but the mid-range Android phone on an unstable connection.

Accessibility came third. Who becomes excluded if this implementation fails?

Those lenses didn’t replace designers. But they created a structure for making thoughtful decisions.

When visual choices couldn’t be defended clearly, I stayed conservative. I reused existing patterns. I extrapolated from the designer’s previous decisions instead of inventing something new.

That restraint is one of the hardest parts.

When design guidance disappears, engineers are often tempted to fill the creative vacuum and prove they can do both jobs.

That instinct is usually wrong.

The goal is continuity. Not reinvention.

Whenever I considered a bold decision, I asked myself:

“If the designer were here, would this surprise them?”

If the answer was yes, I stepped back.

When the designer eventually returned, the feedback was minimal. Not confusion. Just small refinements.

That experience reinforced the entire framework for me.

It also highlighted where design instinct remains hardest to replicate: the subtle decisions around proportion, spacing, weight, and balance that designers often recognize immediately.

Design-minded engineering can get extremely close. Understanding where “close” still falls short is part of the skill itself.

---

Familiar industry mistakes

Part of building design fluency is learning to recognize where things went wrong.

The industry offers no shortage of examples:

• Snapchat’s 2018 redesign,
• the hamburger menu obsession,
• dark patterns optimized for conversion at the expense of trust,
• AI-generated interfaces that look convincing but behave incoherently.

The hamburger menu is especially instructive.

At the time, it felt like an elegant engineering solution. Mobile screens lacked space, navigation consumed room, so everything was hidden behind a single icon.

Problem solved.

Except user behavior consistently revealed something else: people rarely engage with navigation they cannot see.

Features hidden inside hamburger menus consistently received lower engagement.

The logic behind the solution was technically sound. But it failed human behavior.

The design-minded engineer’s role in those situations is not necessarily to argue emotionally about aesthetics. It’s to recognize when technically logical decisions conflict with actual user interaction patterns.

“Apply and extrapolate. Don’t originate.”

AI makes this even more important

AI has made generating UI code dramatically easier. Working interfaces can now appear within minutes.

That is exactly why design judgment matters more than ever.

AI is an incredibly useful tool for design-minded engineers. It can:

• generate localization variants,
• simulate gap states,
• produce prototypes quickly,
• identify accessibility issues before review.

But AI cannot reliably judge whether something feels right.

It cannot determine whether an animation improves an interaction or merely decorates it.

It cannot understand that a loading state lasting 200ms on a fast connection may become unbearable on a train with weak signal.

The bigger risk is not that AI replaces designers.

The real risk is that engineers begin outsourcing design judgment itself.

Need an error state? Ask AI. Need loading copy? Generate it automatically. Need mobile behavior? Prompt for several options.

Individually, these choices may seem acceptable. Collectively, they create products with no coherence, no perspective, and no evidence that anyone thought deeply about the user experience.

The design-minded engineer becomes the counterbalance.

They are the person asking:

• Does this match real user behavior?
• What performance cost does this introduce?
• Who gets excluded?

Those questions require judgment. Not better prompts.

Execution can be accelerated. Judgment cannot.

---

Design fluency is learned

Over 25 years working in highly design-focused engineering environments, I’ve learned something important:

Design fluency is not innate talent.

It is a skill.

A skill that can be practiced, developed, and refined.

The engineer who notices spacing inconsistencies early in their career eventually notices hierarchy problems. Later they begin recognizing broken interaction patterns before designers even mention them. Eventually they become the engineer designers specifically want involved in difficult product decisions.

None of that happens instantly.

It begins with a simple decision:

Caring about what you build beyond whether it technically works.

The flaws I recognize in code reviews today would have been completely invisible to me in 2002.

The AKQA designer who overlaid those Photoshop layers taught me how to look carefully.

That ability was not talent. It was learned perception.

And engineers who develop that perception eventually become the engineers designers no longer need to chase.