What is design engineering? How design engineers work in a software product team

Design engineering is the practice of making interface decisions in code, where the product will actually live, with real states, real data and real motion. A design engineer works between product design and front-end engineering: they prototype in the browser, build the components a design system is made of, hold the quality bar when designs become code, and review what ships against what was meant.

This guide is about software. If you came for mechanical or product engineering, the same title means drawing and specifying physical parts, and this page will not help. It also does not cover software architecture, which is software design in the classic sense.

What design engineering is

The short version is designing in the material. A static design file shows one moment of a screen. A product has many: empty, loading, partial, failed, too long, too narrow, no permission. It also has timing, focus order and the feel of a drag. A design engineer makes the decisions about those moments in the browser, because that is the only place they can be seen and felt.

Two common descriptions miss the point:

• "A designer who codes." Plenty of designers can write some HTML. Design engineering is defined by where the decisions are made, not by which tools a person can open.
• "A front-end developer with taste." Front-end engineering delivers and maintains an agreed interface. Design engineering shapes and tests the interface while it is still being decided.

Our position is that design engineering is a lens a software team can adopt, not a rename of front-end development. It is the decision to make interface choices where they will live. That decision can sit with one person, a pair or a whole team, but someone has to own it.

Where the term comes from

There is no single origin, and the companies that use the title describe it in their own words. A few public sources, read in their own pages:

• Vercel. In Design Engineering at Vercel (29 March 2024), the team writes that its design engineers "blend aesthetic sensibility with technical skills" and "work closely with designers to implement designs, skipping the traditional handoff process". A designer sketches the start and iterates with a design engineer "in Figma or code" to reach the final design.
• Stripe. Stripe's Design Engineer, Expansion listing says the role will "concept, prototype, and build new experiences" and "utilize, maintain, and extend our design systems".
• Google uses a different title for a close relative. Its piece Why Google needs UX engineers describes people who "sit at the intersection of design and engineering and speak the language of both", with prototyping at the centre of the work.
• David Hoang, writing on design engineering in March 2024, argues that it "is not simply a rebrand of product design" and that calling it product design plus front-end development "dilutes the value the practice brings".

Other titles you will meet for overlapping work include UX engineer, creative technologist and design technologist. The labels differ; the shared idea is that someone owns the quality of the interface as built, not only as drawn.

The four kinds of work

Most design engineering falls into four kinds of work. Each produces something different and hands it to someone different.

Coded prototypes

A prototype in code is worth building when a picture cannot answer the question. A clickable design file answers questions about layout and navigation well. It cannot show how a table behaves with three thousand rows, what a drag feels like on a trackpad, or what happens when a response takes four seconds. A coded prototype answers one of those questions, with real or realistic data, and then stops. We cover the choice in more depth in when to prototype in code instead of Figma.

A prototype in code also changes who can take part in the review. When we built shared patterns for Benchmark Gensuite as working prototypes in HTML, CSS and JavaScript, an engineering stakeholder asked whether drag and drop would need an external library, since Bootstrap 5 does not support it natively. The question reached the team during design review, while they could still act on it. A static file would have hidden it until the build.

Front-end design systems

A design system only works once it exists in code. Here the design engineer turns decisions into tokens (named values for colour, spacing, type and motion), components (the table, the editor, the date picker) and documentation that says what each one is for and how it behaves. Tokens now have a shared format: the W3C Design Tokens Community Group announced the first stable version of its specification, 2025.10, on 28 October 2025.

The quality bar is every state, not the happy path: empty, loading, error, disabled, overflowing, keyboard-only. Each state should be visible in one place (Storybook or whatever the team already uses), so designers, developers and testers review the same thing, and each should carry tests for appearance, behaviour and accessibility. We describe how we approach this on our front-end design systems page.

Design-to-code implementation

This is the most familiar kind of work: taking an agreed design into production code. What separates design engineering from ordinary implementation is the bar it holds and the questions it asks before building:

• What does this screen do with missing, long or unexpected data?
• What happens at the smallest supported width, and at the largest?
• Can it be used with a keyboard alone, and does it meet WCAG 2.2?
• How does it move, and does the motion help someone understand what changed?
• Which existing component should this use, and what must change in that component instead of here?

If you are moving a design file into a React codebase, our Figma to React guide covers the points where fidelity slips between file and build.

Implementation review

The last kind of work is reading what was built against what was intended. A design engineer checks the running product, not screenshots: component settings, colour and spacing, permissions, keyboard use, errors and small screens. The output is a list of gaps, each shown against the intended design with its cause, ordered by what users will notice most. The cause matters as much as the gap. A gap that comes from an unclear specification will come back unless the handover changes.

Not every difference is a defect. Developers make sensible changes during a build, and a good review records those so the design can catch up.

How it fits a team

A design engineer sits between product design and front-end engineering, and the role only works when the handover in each direction is clear.

• From design to design engineering: the product designer hands over the intent, the user problem and the questions still open. They do not need to hand over every state drawn; deciding those states is part of the design engineer's job.
• From design engineering to engineering: the design engineer hands over working code or a working example, the rules behind it and the states it must handle. Engineers review it, merge it and own it from then on.
• Back the other way: engineers bring constraints (performance, data shape, platform limits) early, and the design engineer brings them into design decisions before they become surprises.

Who owns what, in short:

The table describes the work, not job titles. In a small team one person may cover two columns. If you are deciding whom to hire, we compare the roles in UX/UI designer vs design engineer.

What AI code generation changed

AI tools now produce front-end code quickly, from prompts, screenshots and design files. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they were using or planning to use AI tools in their development process. In the same survey, more developers distrusted the accuracy of AI tools (46%) than trusted it (33%), and the most common frustration, named by 66%, was "AI solutions that are almost right, but not quite".

"Almost right" is exactly where interface quality lives. Code that compiles and renders the happy path can still be wrong on the parts a design engineer owns: the empty and error states, focus order, the component that already exists and should have been reused, the motion that explains a change. As more code arrives faster, judging and shaping it matters more, not less. The scarce skill is deciding what the code should feel like and saying no to what merely compiles.

Figma's CTO, Kris Rasmussen, made a related point in Why are we so afraid of code as a commodity? (26 June 2024): "What won't be commoditized is being able to identify and interpret what users need …"

In practice, AI shifts design engineering in three ways:

• Prototypes get cheaper to start, so the discipline is in choosing the question and throwing the prototype away when it is answered.
• Design systems become instructions for machines as well as people. Components with written rules, named states and clear usage notes give coding assistants something to reuse instead of something to copy and modify.
• Review becomes the main event. When a team accepts generated code, someone has to check it against intent, not only against tests.

We look at the tools themselves in AI design-to-code tools for product teams, and at what reviewing generated interface code is for in accepting AI-generated front-end code.

Signs you need it

You probably need design engineering, as a role or as a habit, if several of these are true:

• Screens look right in review and wrong in production, and nobody can say where the difference came from.
• Designers and engineers argue about behaviour that neither side can show the other.
• The same component exists three or four times in the codebase, each slightly different.
• Your product is data-heavy, and design files never show what real data does to the layout.
• Important interactions (dragging, editing in place, complex filtering) are decided late, during the build.
• AI-generated front-end code is arriving faster than anyone can judge it.
• Accessibility problems are found after release, not before.

If none of these is true, a strong product designer and a strong front-end engineer working closely may be all you need.

How to start

You do not need to restructure a team to begin. A practical sequence:

1. Pick one question a static file cannot answer. A drag interaction, a dense table, a slow response. Build a coded prototype for that question alone, and decide from it.
2. Pick one component that keeps being rebuilt. Make one shared version in code, with every state visible and documented, and point new work at it.
3. Add an implementation check before release. Compare the running build with the intended design on real data and small screens, and record the cause of each gap.
4. Write down who owns states and edge cases. If the answer is "whoever builds it", that is the gap design engineering fills.
5. Treat generated code as a draft. Agree what a reviewer checks beyond tests: states, reuse, accessibility, motion.

We describe how we take this into client work on our design engineering page, and our coded prototyping page covers the first step in detail.