What's a Design Engineer, Anyway?
The other day I typed a small confession into Claude: I have no idea what to call my role anymore.
It started, as these things do, on LinkedIn. Suddenly every other person in my feed is a Design Engineer or looking for one. New job postings, new bios, new conference talks. And I realized that despite 25 years in this industry, I couldn't actually define the term. I had three competing theories and no way to pick between them.
Theory one: it's an engineer with good design and product taste. Someone who came up through code but can be trusted with the pixels and product decisions.
Theory two: it's a designer who uses AI to write code, but other than HTML/CSS can't really promise you if the more serious code is good enough. (This one felt suspiciously close to home.)
Theory three: it's the unicorn. A person who is genuinely both a designer and an engineer by training.
The first two made sense to me. Both are real, and both got a massive boost from AI tooling. But the third one bugged me. If a design engineer is a true unicorn, why are there suddenly so many of them? Unicorns don't have baby booms.
So I did what I do these days: I asked Claude to research the term, then went down the rabbit hole myself, checking its homework. Here's what I found, sources included.
The first obvious thing it came back with is that the term is old. I assume we all know this, but for most of its life, "design engineering" had nothing to do with screens. A design engineer sat at the intersection of industrial design and mechanical engineering, the person responsible for making sure a physical product actually works and can actually be made. The UK has had a professional body for them, the Institution of Engineering Designers, since 1945, and Imperial College London runs an entire school of Design Engineering that grants real engineering degrees. We borrowed the name from people who make actual machines.
When tech started to borrow the term, it couldn't stop renaming it. The design-and-code hybrid has gone by UX engineer, design technologist, creative technologist, and a handful of similar titles over the years. Heck, I've even hired some amazing UX engineers and creative technologists (Hi Donnie and Dave, to name a few…). Google has had a formal UX Engineering track for over a decade, and Vercel built an entire team around the role. Even the underlying tension is old news: Chris Coyier described the great divide between the design half and the JavaScript half of front-end work back in 2019, and Brad Frost later gave the design half a name, front of the front end. The role isn't new. The name just keeps winning different popularity contests.
And the purist definition, it turns out, is my theory three. In the strict sense, a design engineer is its own discipline, focused on the exact point where design decisions meet technical implementation. Not "kinda good at both"; a designer who can build their own solutions, end to end. That's essentially the case Jim Nielsen makes, and InVision (remember them?) published a whole Design Engineering Handbook about the discipline back in 2020. That population was always tiny, which is exactly why the title stayed niche for so long.
Which brings us back to the baby boom question. If the unicorns were always rare, where did this flood come from?
First, an honest aside: I couldn't find hard numbers on the flood itself. Job statistics for "design engineer" are dominated by the mechanical kind, so anyone showing you a tidy chart is probably measuring the wrong profession. What I can show you is the pile of anecdotes: Vercel, Linear, The Browser Company, and Anthropic have all been hiring design engineers, the title now has its own job board, and the essays about its rise keep coming. Something is clearly happening.
But it's not a baby boom. It's a title migration.
Here's what I think is actually happening… the bar for "can implement" collapsed. First slowly: component libraries like shadcn/ui, Radix, and Headless UI meant you no longer had to build every button and dropdown from scratch. Then all at once: tools like Cursor, v0, and Claude Code mean a designer can express ideas in working code without mastering every syntax detail. So the people from theory one and theory two can now credibly adopt the label that used to belong only to the theory three unicorns. Same herd, new name tags.
There's a piece by Anna Lefour, The Design Engineer Symptom, that takes this a step further. She reviewed a wave of design engineer job descriptions and found them wildly inconsistent, sometimes 70% design and 30% development, sometimes the reverse, sometimes something else entirely. Her argument is that this isn't just sloppy naming. It's organizations trying to scope roles in real time, while the old boundaries between research, design, engineering, and product management quietly become negotiable. The title is a symptom, not a definition. And her conclusion is the one that's stuck with me: "What matters now is the scope you're willing to own, and whether you can deliver tangible work within it."
I can't stop thinking about that last line.
Because by that logic, my own situation is less confusing than I thought. I'm a designer who ships working products by directing AI implementation (I wrote about that shift in Drawing With Words). An engineer may need to PR the code to ensure it's not breaking anything etc., but that happens even with other engineers, not only me. So I seem to land on theory two, but with a couple of decades of taste stacked on top. Arguably it's the configuration the market is rewarding right now, since taste is the scarce part and code generation is quickly becoming a commodity. "Design Engineer" is a defensible label for it. But so is "designer who ships".
And the people who'd quibble over whether I can hand-review every line of the code? I suspect they're arguing about the wrong thing.
So, did I figure out what to call my role? Sort of. Calling myself a design engineer just seems weird, I get imposter syndrome. Besides, the industry hasn't decided yet, and maybe it doesn't need to. Maybe titles were always just handles, something for recruiters and org charts to grab onto, and the real question was never "what are you called". It was "what can you own".
Or do we even need to change our titles at all? Do titles change just because the tools did? I dunno. If you think about it, PMs, product designers, and engineers all share the same tools now, yet everyone keeps their role's strengths and charters, even if the edges have gotten a bit blurry. When I partner with an engineer, we're both generating code, but I come at it from a designer's perspective, they come at it from an engineering perspective, and we meet in the middle. What if we just expect product designers to ship code, the same way we used to expect them to do the wireframes, or something…
Or maybe I'm overthinking it again.