Most product teams know the feeling. The design is approved. The engineering is done. The thing works. And yet — when you open it next to a polished competitor, it feels two grades behind. The hover states are abrupt. The empty states are afterthoughts. Density is inconsistent. Motion is either missing or distracting. The product works, but it does not feel like the design.

The gap is real, and it has a name now. The discipline that closes it is called design engineering.

The short definition

A design engineer is a hybrid practitioner who writes production frontend code and makes visual, motion, and interaction decisions inside the codebase rather than inside Figma. The role exists because the last 20% of product polish — the part that separates good software from forgettable software — cannot be specified in a design file. It has to be built, evaluated, and tuned in the actual running product.

Where design engineering came from

The term went mainstream in 2022 when teams like Linear, Vercel, Stripe, and Arc started hiring openly for "design engineers" and putting them at the center of the product. The role has existed for much longer — Apple has had design engineers in everything but name for two decades, and any small studio that ships polished work has always had one or two people doing this job.

What is new is the explicit role, the explicit budget, and the acknowledgment that the work is genuinely distinct from both "designer" and "frontend engineer."

What a design engineer actually does

The role varies by team, but the work clusters into four areas.

Motion and micro-interactions

Every state transition in a product — open, close, expand, collapse, hover, focus, drag, drop — has an opinion baked into how it animates. A design engineer owns these opinions. They write the easing curves, the durations, the choreography of multiple elements moving at once. They decide what eases and what snaps. They make the product feel responsive even when the network is slow.

Density and rhythm

Designers usually specify spacing at the component level — 16px here, 24px there. Design engineers think about spacing as a system — how density changes across breakpoints, how rhythm holds across a long table, how a dashboard feels with 3 rows versus 300. The work is typographic in spirit and almost always requires running code to get right.

Edge states

The states that never show up in Figma: empty, loading, error, "you have one item," "you have one thousand items," skeleton, optimistic update succeeded, optimistic update failed and we are rolling back. Most products are 70% edge states by surface area and 5% by design investment. Design engineers fix that ratio.

Production-grade prototyping

When a new feature is ambiguous, the cheapest way to resolve it is often a working prototype, not a Figma file. Design engineers ship these prototypes in branches off the real codebase, using the real data and the real component library. The prototype is throwaway, but everything around it is real, so the decisions stick.

Design engineer vs. frontend engineer

The two roles share tooling and overlap in skill, but the work and instinct are different.

  • Frontend engineer. Owns architecture, performance, state management, build tooling, accessibility infrastructure, framework choices, data fetching. Asks how do we build this well.
  • Design engineer. Owns visual fidelity, motion, density, interaction feel, edge-state design, component-level polish. Asks how do we make this feel right.

A good frontend engineer can do design engineering, and vice versa — but few do both with equal energy. Teams that succeed at polish usually let people specialize.

Design engineer vs. designer

The simpler distinction is the tool. Designers work primarily in Figma, Sketch, or another canvas tool. Design engineers work primarily in the codebase. When a designer ships a design, the handoff is a file. When a design engineer ships a design, the handoff is a pull request.

The deeper distinction is medium. A designer composes static artifacts that imply a product. A design engineer composes the product itself, including the parts that cannot be drawn — the sixteen milliseconds before a click registers, the way a sidebar transitions on a slow laptop, the moment a list re-orders.

When you need a design engineer

Not every product needs one. The role is most valuable when:

  • The product is in a category where craft is a differentiator — developer tools, consumer SaaS, creative software, premium B2B.
  • Designers and engineers are already communicating well, but the shipped product still feels less polished than the Figma file.
  • You are doing a major redesign and the team needs someone who can hold the vision in code, not just in a file.
  • You are competing against a well-funded, design-led incumbent and polish is part of your pricing power.

You probably do not need one if your product is admin software, an internal tool, or a B2B workflow where users grade you on whether the workflow ships, not how it feels.

How to hire one

Three signals that distinguish a real design engineer from a frontend engineer who likes design:

  1. Public work that ships. Live URLs, not dribbble shots. The work should run in a browser and survive inspection at multiple breakpoints.
  2. Opinions about specific milliseconds. Ask them about animation durations. A real design engineer will have defended choices about why 180ms is right and 250ms is not.
  3. Comfort starting in code. Ask them how they would explore a new feature. If the answer starts with "I'd open Figma," they are a designer who codes. If the answer starts with "I'd branch and prototype with real data," they are a design engineer.

The trade-off nobody mentions

Design engineers are expensive and rare. Salaries at the top end rival senior frontend engineers and senior product designers — often higher than either individually, because the supply is small.

The honest answer for most teams is: you do not need a full-time design engineer. You need a design engineering practice for eight to sixteen weeks at a specific stage of your product, and then you need it again at the next inflection. That is exactly the kind of work a small software engineering studio is structured to do well — and it is one of the practices we run at Kirin.

FAQ

What is design engineering?

Design engineering is the discipline of making visual, motion, and interaction decisions inside a production codebase rather than inside a design file. Design engineers write frontend code and own the last 20% of product polish — motion, density, micro- interactions, edge states — that cannot be fully specified in Figma.

What is the difference between a design engineer and a frontend engineer?

A frontend engineer owns architecture, performance, state management, and build tooling — the question of how do we build this well. A design engineer owns visual fidelity, motion, density, and interaction feel — the question of how do we make this feel right. The tooling overlaps, but the instincts and daily work are different.

What is the difference between a designer and a design engineer?

A designer composes static artifacts in Figma or Sketch that imply a product. A design engineer composes the product itself in code, including the parts that cannot be drawn — animations, transitions, timing, and runtime behavior. The handoff from a designer is a file; the handoff from a design engineer is a pull request.

Why are design engineers important?

They close the gap between an approved design and a shipped product that actually feels like the design. In categories where craft is a differentiator — developer tools, premium SaaS, creative software — that gap is often the difference between a product that wins on polish and one that loses on it.

Do small teams need a design engineer?

Most small teams do not need a full-time design engineer. They need a design engineering practice for a defined period — typically eight to sixteen weeks at a product inflection point — and then again at the next inflection. That is one of the most common uses of a small senior studio.


Design engineering is one of five practices at Kirin. We embed with product teams for eight to sixteen weeks and ship the last 20% of polish — in production code, not Figma.