What Is a Design Engineer?

Search for “design engineer” and half of what comes back is about SolidWorks.

Blueprints. Schematics. Machine parts. CAD licences. A salary page describing a job that has nothing to do with the one on my business card — and the same two words heading both.

I call myself a design engineer. I run a product design studio, and I also ship the code. So I have a job title that needs a second sentence nearly every time I say it out loud, because the first result for it describes a different profession.

So let me write the page I wish that search had returned. What a design engineer is. Why the term means two jobs. What the work actually looks like from the inside, and how anyone gets there.

What is a design engineer?

A design engineer, in software, is a designer who ships production code — one person who shapes the interface and builds it, so that the design and the running product are the same thing rather than two versions of it. The role sits in the gap that used to exist between a designer's mockup and an engineer's implementation, and its whole purpose is to close that gap from inside.

Vercel, one of the companies that built a team around the title, describes it in its own account of the role:

Design Engineers at Vercel blend aesthetic sensibility with technical skills. This allows us to deeply understand a problem, then design, build, and ship a solution autonomously.

The word doing the work in that sentence is autonomously. Not “implements designs”. Not “bridges design and engineering”, which is what every job description says and nobody can picture. Autonomous means a single person can take a problem from “this is wrong” to “this is live” without handing it to anyone.

That is the job. Everything else is detail.

Why does “design engineer” mean two different jobs?

Because the title existed in mechanical and industrial engineering long before software borrowed it, and search engines treat the two as one. In the older sense, a design engineer turns product requirements into physical specifications: parts, tolerances, materials, assemblies. In the newer software sense, a design engineer turns intent into interface.

This matters more than it sounds, because the numbers attached to the title are usually the mechanical ones. PayScale's widely-quoted design engineer salary page puts the US average at $79,209 across 3,860 salary profiles — and describes the job as creating blueprints and schematics for systems, machines, and equipment, listing CAD, SolidWorks and AutoCAD as the skills.

Nothing wrong with that number. It is simply not about the job this article is about. If you are pricing a software design engineer role, or deciding whether to become one, a salary figure that answers the query without distinguishing the two will mislead you, and most of them do not distinguish.

What does a design engineer actually do all day?

A design engineer spends most of the day in the place where design decisions become expensive — the moment an idea meets a real browser, real data and a real keyboard. That is where mockups stop being true.

A static design shows one state of one screen at one size. The product has to survive every state: empty, loading, failing, half-typed, too long, right-to-left, keyboard-only, a screen reader, a slow connection, a user who double-clicks. The mockup is a hypothesis. The running interface is the test.

The biggest change is to the handoff, because in this model there mostly is not one. Vercel describes the flow like this:

A Designer sketches the start and iterates with a Design Engineer in Figma or code to produce the final design.

Read what is missing from that. No specification document thrown over a wall. No two-week wait to discover the animation was impossible. No meeting to argue about why the built version looks different from the drawn one. The final design is produced in the collaboration, in whichever medium the problem needs.

In practice the day looks like this:

• Prototyping what Figma cannot show. Motion, keyboard behaviour, touch, scroll, real loading. Some design questions only have answers in code.
• Weighing cost against experience. Vercel puts it as considering implementation cost versus the impact on experience — the judgement call that decides whether a detail ships.
• Building components that other people build with. A button used once is a button. A button used by forty screens is a decision made forty times.
• Owning the details nobody specified. Focus states, error messages, reduced motion, the gap between two elements at an awkward width.

That last one is most of the job, and it is invisible when done well. I have written about building while nobody claps — the four months on a desk joint nobody asked about. Interface craft is the same trade. Nobody praises a focus ring. Everybody notices when it is missing.

Design engineer vs product designer vs frontend engineer

The three roles overlap, and the cleanest way to separate them is by what each one is ultimately accountable for.

What does a product designer own?

A product designer owns the problem and the experience: what the product should do, for whom, and how it should feel. The output is a decision about behaviour, usually expressed as flows, prototypes and design files. A great product designer may never write production code, and does not need to.

What does a frontend engineer own?

A frontend engineer owns the correctness and scale of the client: state, data, performance, architecture, tests. The output is software that works reliably for everyone. A great frontend engineer may not make visual or interaction decisions at all, and does not need to.

What does a design engineer own?

A design engineer owns the quality of the interface as it actually runs — the place where the first two meet. The output is the shipped experience itself, not a picture of it and not merely a working version of it.

The honest version is that a design engineer is rarely the best designer on a team or the best engineer. The value is the missing translation cost. Every decision that would have crossed a handoff gets made once, by one person, in the final medium.

What skills does a design engineer need?

A design engineer needs taste and the ability to ship, in roughly equal measure — and the hardest part is that both have to be real, not decorative. Vercel publishes six Design Engineer principles, and they read less like a skills list than a temperament:

• Obsess over usefulness — solve real problems for users and teammates.
• Own the whole experience — shape the product, design the interface, ship the code.
• Understand the constraints — know the user, product, code, business, and tradeoffs.
• Build for everyone — design across skill levels, abilities, and contexts.
• Make it excellent — scope small enough to do it well.
• Make the team better — be kind, direct, and low ego.

Notice that not one of those is a technology. Underneath them sits the practical stack, which is well understood and changes every few years:

• Visual and interaction design: typography, spacing, hierarchy, motion, colour, and the judgement to know when to stop.
• The web platform: semantic HTML, modern CSS, accessibility, and how browsers actually render.
• A component framework: in practice React and TypeScript for most teams right now.
• Design systems: tokens, components, variants, and how a decision propagates.
• Design tooling: Figma, and increasingly treating design files as data rather than pictures.

If I had to rank them, I would put accessibility and restraint at the top. Both are skills nobody sees until they are absent, and both separate interface work that looks right in a screenshot from interface work that holds up in someone's hands.

Why is the design engineer role growing now?

The role is growing because the expensive part of interface work moved from making screens to making decisions about them, and AI accelerated that move. Generating a plausible screen is now close to free. Deciding which screen is right, and making it survive real use, is not.

I argued this in what a product designer actually does in the age of agentic AI: UI execution is being commoditised, UX judgement is not. The design engineer is where that judgement becomes concrete, because the judgement has to be exercised in the medium the model is now producing — code.

There is a second reason, less discussed. When generated interfaces are cheap, the scarce skill is recognising what is wrong with one. A model will happily produce a form with no error states, a modal that traps nothing, a colour pair that fails contrast. It looks finished. It is not. Somebody has to know the difference, and the person who knows it best is the one who has shipped enough interfaces to have been burned by each of those.

It is the same pattern I wrote about in why most SaaS products don’t fit the market: products rarely lose on features. They lose on the thousand small frictions between a feature and a person. That is design engineering's territory, precisely.

Why design engineers think in systems, not screens

A design engineer builds systems because a system is a way of making a decision once instead of forty times. I put it in five words in August:

Build your product as a system.

A design system is often described as a component library, which undersells it. What it really is, is a store of decisions. The spacing scale is a decision. The focus style is a decision. The way an error message is phrased is a decision. Encoding them means nobody has to make them again at eleven at night under a deadline, which is when bad decisions get made.

This is the design version of an argument I made about something that looks unrelated. In Poverty Loves Indecision, the point was that every decision you remake each morning is drawn from a limited account, and the people who get furthest are the ones who stop spending on the same question twice. A design system is exactly that, for a product. It is routine, applied to interfaces.

I built one. rakibulism-ui is a code-first React design system: 43 components, design tokens defined in TypeScript, and 119 behaviour tests that gate every change. Its tokens are the part that behaves most like a store of decisions — every component reads them, so overriding one re-themes everything at once.

How do you become a design engineer?

You become a design engineer by shipping interfaces end to end until the gap between what you imagine and what you can build closes — there is no single credential, and the portfolio is the proof. People arrive from both directions, and each has a different thing to learn.

If you are a designer who wants to code

• Learn HTML and CSS properly before any framework. Most visual bugs are CSS misunderstandings, and frameworks hide that until they cannot.
• Rebuild one of your own designs in code, including every state you did not draw. The states you skipped are the curriculum.
• Learn accessibility early. It changes how you design, not just how you build.
• Then learn a component framework, and build a small component library of your own. Nothing teaches systems thinking faster.

If you are an engineer who wants to design

• Study typography and spacing before colour. Most interfaces that look amateur have a spacing problem, not a colour one.
• Copy interfaces you admire, pixel for pixel, then ask why each decision was made. Taste is mostly pattern recognition earned by paying attention.
• Design something from a blank page and ship it to real people. Implementing someone else's taste teaches you less than exposing your own.
• Learn to cut. The skill is less adding polish than removing everything that is not needed.

Either way

Build things in public, finished. A design engineer's portfolio should be live URLs, not screenshots — the entire claim of the role is that the design and the working product are the same thing, so show the working product. Mine is a mix of small tools: a Figma plugin, an icon browser, a design system, and the site you are reading.

And do not wait for the title. Almost nobody is hired into it first. People do the work, and the title catches up.

The key insight

Here is what I think the role actually is, underneath the job descriptions.

A design engineer is not a designer who learned to code, or an engineer who learned taste. It is someone who refuses to let the meaning of a decision get lost in translation — who will not accept that what was imagined and what shipped are allowed to be different things.

That refusal is a skill, and like any skill it compounds. I made the argument in The Only Way to Build a Business Without Owning Assets: skill travels with you across every venture and becomes more valuable the more specialised it gets. Four of mine failed. The judgement I built in them did not.

And in a moment when interfaces can be generated in seconds, the value moves entirely onto that judgement. The same shift I described in 68% of Searches Now End Without a Click applies here: anything that is only ever output gets commoditised. What survives is the thing output cannot contain — the decision about what is right, and the craft to make it true.

So if you are asking whether to become a design engineer, the question is not whether you can learn both tools. You can.

It is whether you care enough about the gap between the idea and the thing to close it yourself.