What is a design engineer, and how do I become one?

A design engineer is a designer who can build, or an engineer who can design. They take an idea from a sketch to working code, and they care about how it looks and feels at every step.

Vercel, one of the companies that made the title popular, puts it simply: "Design Engineers at Vercel blend aesthetic sensibility with technical skills." Their team says the role lets them "deeply understand a problem, then design, build, and ship a solution autonomously."

My own title is Senior Product Design Engineer at HeyOz. In practice that means product design, growth, and engineering in one seat.

The core job is closing the gap between the design file and the shipped product. Vercel's team says they "work closely with designers to implement designs, skipping the traditional handoff process." A designer starts a sketch, and they iterate together "in Figma or code to produce the final design."

Day to day, that usually looks like:

• Building the parts a static mockup cannot show. Vercel notes that "animations, keyboard controls, and touch are better implemented in code."
• Prototyping in code so a team can feel an idea before committing to it.
• Looking after the design system, the tokens and components both designers and developers use.
• Polishing the details engineers might skip and designers cannot ship themselves: spacing, states, motion, performance.

The tools vary. Vercel says it plainly: "There's no fixed toolset for a Design Engineer. There's no best background."

The title is fairly new, and not everyone likes it. Figma's blog described the role as one that "generated heated debate" across design and engineering communities. Critics argue it dilutes both disciplines. Supporters, like Atlassian's David Hoang, say it is essential to building better products.

The same Figma piece gives the strongest case for it: "A design engineer can not only take an idea to a working prototype with little lost in translation, but can spot opportunities and constraints that might otherwise be missed."

The wider trend points the same way. In a 2025 study Figma ran with independent research firms, 64% of product builders said they identify with two or more roles. Titles are blurring, and people who can cross the line between design and code are useful because of it.

One honest trade-off: the role means different things at different companies. Some want a front-end engineer with taste. Others want a designer who can prototype. Read each job post closely before you apply.

The role came out of the work I was already doing:

• My degree is in Computer Science from NUST, so code was never foreign to me, even while I was doing graphic design.
• At NorenzTech I was Lead UI/UX Engineer. I designed the interfaces in Figma and shipped the front-end in code, so I owned both sides of the same product.
• At Vyro I prototyped in code with Figma MCP and Claude Code, and tested ideas roughly 10x faster. It also cut the friction in design-to-dev handoff.
• This site is designed and coded by me, from my own Figma design system and my own brand tokens.

Figma's piece describes this path well: most design engineers did not chase the title. Chasing curiosity, "they gradually skilled up in the areas missing from their stack."

One line I hold firmly: AI helps me build faster, but it never does the thinking, the brainstorming, or the new ideas. Those stay human. If you want to see how I use it, read my AI guide.

You do not need to be an expert on both sides. You need to be useful on both sides.

If you come from design, start with CSS. It is the closest translation of what you already do in Figma. If you come from engineering, start with layout and type, then study a design system you admire.

For the systems part, read my guide on building a design system in Figma. For how this title compares to others, see product designer vs UI/UX designer.

Vercel's own advice to applicants is worth repeating: "Apply even if you've never had the Design Engineer title."

What gets you considered is proof that you can do both halves:

• Ship small things you designed and built yourself. A personal site, a tool, a component you polished until it felt right.
• Show the code next to the design. Link the live build and the repository in your case study, not only the Figma file.
• Write about one decision you could only make because you understood both sides, like an animation you changed after seeing it in the browser.

My guides on building a portfolio and writing a case study cover the format.

1. Pick one screen you designed and build it in HTML and CSS this week, matching it as closely as you can.
2. Add one interaction in code that a static mockup cannot show: a hover state, a keyboard shortcut, or a transition.
3. Read Vercel's post on design engineering (linked below) and note which of their skills you already have.
4. Put the live link and the code in your portfolio next to the design file.