The case for the design engineer

There’s a moment on most projects where a beautiful design gets handed to engineering, and a few weeks later something almost like it ships. The spacing is a little off. The empty states never got built. The loading state is a spinner instead of the thoughtful skeleton from the mockup. Nobody did anything wrong, exactly. The polish just leaked out through the gap.

After years on both sides of that gap — first as a designer, then increasingly as the person writing the front-end too — I’ve become convinced the handoff itself is the problem, not the people on either end of it.

What gets lost in translation

A static mockup can only describe the happy path. It can’t easily express how a list feels when it’s empty, how an error recovers, what happens on a slow connection, or how a layout bends at an awkward breakpoint. Those details are most of the actual experience, and they’re exactly the ones a flat artboard can’t carry.

So they get decided twice: once by a designer who imagined them, and again by an engineer reconstructing that intent under deadline. Every translation step loses a little signal.

Closing the gap

The fix isn’t “designers should code” or “engineers should design.” It’s that somebody on the project should be fluent enough in both to hold the whole experience in their head — to design a component and immediately feel how it behaves in the browser.

That’s what I mean by a design engineer: not a unicorn who’s elite at both, but someone comfortable enough on each side to keep intent intact from Figma to production.

// The empty state isn't an afterthought — it's part of the design.
function Inbox({ messages }: { messages: Message[] }) {
  if (messages.length === 0) {
    return <EmptyState title="You're all caught up" />
  }
  return <MessageList messages={messages} />
}

Why it matters more now

The tooling has quietly made this easier than it used to be. Component-driven frameworks, design tokens, and tools like Figma’s variables mean design and code can finally share a vocabulary. The distance between “the design” and “the build” has never been shorter — which makes it a strange time to keep insisting they’re separate jobs.

I’m not arguing every team needs to reorganize around this. But on the projects I take, collapsing that gap is the single biggest lever I have on quality. It’s most of why I work the way I do.