I recently watched a talk about design engineering that put into words something I've been feeling for a while now. There's a gap in how most teams build software, and it's been bothering me.
Here's the setup: you've got designers who care deeply about how things look, and engineers who care deeply about how things work. Both groups are good at what they do. But they don't speak the same language. A designer hands off a Figma file to a frontend engineer who doesn't fully get typography or spacing systems. An engineer tries to explain pagination constraints to a designer who's never thought about state management. And somewhere in that handoff, in that gap between the two sides, quality quietly dies.
Design engineers live in that gap.
So what actually is a design engineer?
There's no single clean definition, but at the core, a design engineer is someone who operates fluently in both code and design, and refuses to treat them as separate things. They're the interpreter. They can look at a Figma mockup and already see the component tree in their head. They can take a messy backend API and figure out how to turn that into something that actually feels good to use.
What's interesting is that design engineers aren't all the same. There's a whole spectrum. Some are obsessed with the last mile of polish — they'll take a feature that's "done" and add the animations, the transitions, the little details that make it feel alive. Others are deep in design systems, building component libraries and making sure the codebase is as clean and consistent as the product itself. Both are needed. The common thread is that they all care about how the interface feels, and they push for that extra ten percent that most people skip.
How is this different from a frontend engineer or a designer?
Fair question. A frontend engineer gets a design and builds it out. They'll make it work, match the spec, ship it. But they often lack the taste (more on that word in a second) to make decisions on their own about the stuff that wasn't in the spec. Most Figma designs are static. Nobody specced out what happens when the button transitions between loading, in-progress, and completed states. A frontend engineer sees three states and implements three states. A design engineer sees an opportunity to make that tiny interaction memorable.
Full stack engineers have their skills spread even wider, back to front. They're trying to ship the product, and they'll gloss over details that a design engineer would obsess over.
And designers? Their work ends in Figma. They can make something beautiful, but they can't browse a website in Figma. A design engineer can design the thing and build it. That handoff stage in between? They skip it entirely.
Why we actually need this role
Three reasons stood out to me.
The slop problem. We're drowning in AI-generated garbage right now. Someone opens up an AI coding tool, types "make me a website," and out comes purple gradients, bad spacing, mismatched colors, terrible copy. And here's the thing — regular people can feel it. They might not be able to articulate what's wrong, but they know something is off. There's no human warmth in it. Design engineers are the line of defense against that. They make sure what ships actually feels like a human made it with care.
Taste. This is the big one and I want to spend some time on it. The talk had this great demo showing two versions of a button that transitions between states. One version just swapped the text but the container stayed the same width. The other version had the container smoothly morphing to fit the new content. Most apps would either make the button full-width to dodge the problem, or just skip the transition entirely. A design engineer spots that moment and thinks "this is where I can add something people will remember."
Speed. With AI tools, design engineers can move into unfamiliar territory fast. The speaker built a whole sound lab using web audio APIs despite having zero experience with sound design. Before AI, that's two weeks of research minimum. Now it's a few hours. But here's the key part — the AI output was ugly. Raw buttons, no style. The design engineer's job was to inject their taste into it. Different pops of color, morphing objects, little touches that turned a functional tool into an experience. That last layer is what makes the difference between something that works and something people actually enjoy using.
OK so what is "taste" really
Taste gets thrown around a lot online and people get weird about it. But I think it's actually simpler than the discourse makes it seem.
The talk used this analogy of a famous music producer who's been in the room for some of the biggest songs ever made. The thing is, he's not really a musician himself. He's the guy people go to and ask "is this good or is this bad?" People trust his judgment. That's taste. As a design engineer, you need to be the person in the room who can receive a design and say "let's take a step back, let's try something else, let's experiment." You need that opinionated eye.
And here's the part I really appreciated — the speaker was adamant that taste is not something you're born with. You can develop it. Three ways:
Study. Go look at the best products. Don't just use them, inspect them. Try to understand why they feel good. What's the typography doing? What's the animation timing? Over time you build this sensitivity, this mental archive. The talk had this cool moment where the speaker zoomed into a well-known product's navigation and spotted that during a transition, the inner content was slightly overflowing its container. Tiny thing. Almost invisible. But that kind of eye comes from years of studying and building.
Notice. Train yourself to spot inconsistencies. There was a demo with three animated elements where the ones on the edges shared the same timing but the middle one was slightly different. Most people wouldn't consciously spot it, but they'd feel that something was off. That's the "something feels off" that users report but can't describe. A design engineer needs to be the person who can name it.
Build. Copy the best stuff. There's that saying about stealing like an artist. Take a cool interaction you saw in someone else's app, recreate it, change the colors, make it your own. Do this enough times and you start building that instinct for when to use a spring animation versus an easing curve, when to tighten letter spacing, when to leave things alone.
The form vs. function balance
One thing that really resonated with me was the discussion about knowing when not to add animation. The speaker talked about an early career mistake where they were obsessed with blur effects and wanted everything to feel like it was morphing. Their manager basically said "that's not what this product needs. People want something sharp and fast."
And that shifted their whole perspective. If you're building a tool that people use hundreds of times a day, that beautiful loading spinner is cool the first time and annoying the hundredth time. It's like an unskippable cutscene in a video game — you're just mashing the button to get past it.
The way to think about it: novelty has diminishing returns. Like a power-up in a platformer that only appears once per level. You're always chasing it because it's rare. If it was everywhere, nobody would care. On a landing page, sure, go a bit wilder with the intro animation. But on an app people use daily? The best animation might be no animation. Speed is form when people need to get things done.
How to actually become a design engineer
If you're a designer, you've actually got a head start. You already have the eye. The hard part for you is learning to turn your designs into real code. Start small. Take something you designed and try to build it, even if it's rough. Use AI tools to help bridge the gap. Over time, you'll start designing in Figma and already knowing what the code will look like.
If you're an engineer, you've got the other half covered. Your job is to train your eye. Start studying the products you use every day. Ask yourself why they made that choice with the font, the spacing, the button style. Then try to implement what you notice in your own work.
Either way, you learn by doing. If you're not building, you're not learning.
The portfolio thing
This was a good nugget too. If you're trying to show that you're a design engineer, don't just slap a bunch of polished micro-interactions on a portfolio site. Show that you actually love doing this. Post your experiments, even the rough ones. Show progression. People want to see the care and dedication, the journey from messy early work to where you are now. Reference what inspired you, show your version, put yourself into it. That authenticity stands out way more than a clean grid of components with no personality behind them.
Where this is all going
I think we're heading toward a point where most product teams will have design engineers as a core part of the group, not a nice-to-have. AI is making it possible for anyone to generate a functional website in minutes, which means the bar for "it works" is basically on the floor now. What's going to separate good products from forgettable ones is that human layer — the care, the taste, the feeling that someone actually gave a damn about how this thing feels to use.
We're kind of in a weird renaissance moment. The tools to create have never been more accessible, but that also means there's more noise than ever. The people who can cut through that noise by building things that feel genuinely crafted, genuinely human? That's where the value is heading.
Anyway. Go study some websites. Copy something cool. Ship something ugly and then make it less ugly. That's basically the whole playbook.