What a design engineer does in a software team, and when to hire one

Here's the definition I work to. A design engineer decides how an interface should work, look and feel, and is accountable for that decision reaching users intact. That takes design judgement (flows, layout, type, every state a screen can be in), the ability to build in the real medium, and the habit of keeping one system that designers and developers both use.

It isn't a frontend developer who likes CSS, or a designer who writes a little code. The difference is the yardstick. A frontend developer is judged on whether the feature works; a product designer on whether it solves the right problem. A design engineer is judged on whether what ships is the design, in every state, on every screen size, including for people using a keyboard or a screen reader.

In a large company, design engineers often sit in the design team and own the component library and the hardest interactions. In a startup, they often take a feature from the first frame to the release.

I found no source that settles who used the title first. What I can show is how practitioners described the gap before it had a name.

In January 2019, Chris Coyier wrote The Great Divide on CSS-Tricks: one job title, front-end developer, covered two groups, one centred on JavaScript and application architecture, the other on HTML, CSS, design, interaction and accessibility. In February 2021, Brad Frost named the second group in front-of-the-front-end and back-of-the-front-end web development: people who write semantic markup and CSS, work with designers and build the component library.

The title spread in 2024. In March, Maggie Appleton published A Collection of Design Engineers, describing someone who "sits squarely at the intersection of design and engineering". Most of the people she found worked at a few companies known for interface detail, among them Vercel, Linear, The Browser Company and Replit. Later that month, Vercel's Design Engineering at Vercel described it as a new and increasingly popular role, with designers and design engineers shaping the final design together in Figma or code instead of passing a finished file across.

My reading: the title is new, the work isn't. What changed is that companies began hiring for the combination on purpose.

This is what fills my week on a product, roughly in the order the work arrives.

Interface and interaction details

Most of my time goes on what surrounds the main screen. A menu has to open from the keyboard, close on Escape and return focus to the button that opened it. A form needs a decision about when errors appear and what stays filled in after a failure. A list needs an empty state that says what to do next, and a version with very long names. I draw these in Figma when they change the layout and decide the rest in code, where timing and feedback can be felt.

The design system, in Figma and in code

Tokens and components are the shared language. The Design Tokens Format Module 2025.10, which the W3C Design Tokens Community Group announced as its first stable version on 28 October 2025, gives tokens a vendor-neutral file format with theming. Figma's Code Connect links components in a repository to the matching ones in a design file, so Dev Mode shows real code. My rule: one name per thing, used in both places, changed in both in the same pull request.

Prototyping in the browser

Figma prototypes are good for testing a flow and poor at feel, real data and speed. When the question is whether something feels right or survives real data, I build a throwaway prototype in the browser with the codebase's own components, reviewed on a preview link. Motion is decided there too, with a calmer version for anyone who asked their device for less movement, which browsers expose as the prefers-reduced-motion media feature.

Accessibility as part of the build

My target is WCAG 2.2 at level AA. The W3C's summary of what's new in WCAG 2.2 counts nine success criteria added in 2.2, which became a W3C Recommendation on 5 October 2023. Two are pure design engineering: pointer targets of at least 24 by 24 CSS pixels (or enough space around smaller ones), and a focused item never entirely hidden by something like a sticky footer. Neither problem shows in a static mockup. For menus, tabs and dialogs I follow the W3C's ARIA Authoring Practices Guide.

AI features and agent interfaces

More of my work is now AI: chat panels, summaries, agents that take several steps. People need to see progress, where an answer came from, an approval step before anything changes and an undo afterwards. Google's People + AI Guidebook on explainability and trust frames the aim as helping people know when to rely on the system and when to use their own judgement. I've written up the patterns for AI features people trust; the design engineer's part is that streaming text, partial results and a cancel button are code behaviours, and each needs designing like a screen.

Tools now turn a Figma frame or a screenshot into markup in minutes. Figma's MCP server, for example, generates code from a selected frame and can reuse your real components through Code Connect. That makes the first draft cheap. It doesn't make it right.

Developers say so themselves. In the Stack Overflow 2025 Developer Survey's AI section, 84% of respondents used or planned to use AI tools, and 51% of professional developers used them daily. Yet 46% distrusted the accuracy of the output, against 33% who trusted it. Asked what goes wrong, 66% picked answers that are nearly right but not quite, and 45.2% said debugging AI-written code takes longer. Fewer felt less sure of their own problem-solving (20%) or found it hard to see how the code works (16.3%); only 4% reported no problems.

In interface code, the nearly right draft has a recognisable shape. When I review a generated screen, I check it in this order:

1. Components. Did it use the system's button, input and table, or invent look-alikes with hard-coded colours?
2. States. Loading, empty, error, disabled and very long content. Drafts usually show only the happy path.
3. Keyboard and screen reader. Real buttons and links, labelled inputs, a sensible focus order.
4. Layout under stress. A narrow phone, a long translation, and text resized to 200 percent, which WCAG 2.2 expects to work.
5. Behaviour. A slow network, a double click, a failed request.

In my team, a person who knows the design reviews every change before it merges. That rule is why we can use these tools at all. The checks themselves are in reviewing AI-generated code before it merges.

Nobody is strong at all of these; a good design engineer covers most:

• Visual and interaction design: type, spacing, hierarchy and motion that explains something.
• Deep HTML and CSS: layout, responsive behaviour and what modern CSS does without JavaScript.
• TypeScript and React, or your team's framework: components with clear props and sensible state.
• Accessibility in practice: WCAG, ARIA patterns, testing with a keyboard and a screen reader.
• Systems thinking: tokens, component APIs and documentation.
• Writing: interface copy and pull request descriptions people can follow.
• Judgement about cost: Vercel's post counts weighing implementation cost against the effect on the experience as part of the job.

That last one separates seniors from juniors: a senior knows which detail to fight for and which to drop.

Boundaries blur between companies; this is the usual shape:

On design engineer vs software engineer: a design engineer is a kind of software engineer, judged on the quality of the experience rather than on system architecture. Larger teams need all four roles; a startup's first product often starts with a design engineer and a back-end engineer.

Hire one when:

• Your product's value is in the interface: a dashboard people live in, an editor, an AI feature that has to show its working.
• Several people build screens, and the product has started to drift from Figma.
• Your engineers are strong, but the product looks assembled from default components.
• You ship with AI coding tools and need someone to judge generated interface code against a design.

Wait, or hire someone else, when:

• You haven't tested the idea. Discovery and a clickable prototype come first; my first 30 days of product design shows the order I'd follow.
• You mainly need a marketing site your team edits, where a builder may suit you better, as in Framer, Webflow or Next.js for a startup site.
• The hard part is data or infrastructure, with little interface on top.
• You already have a designer and a frontend developer who sit together and ship well. Don't break a working pair to fit a title.

If you recognise yourself in the first list, this is how I design and build in the same sprint. If the question is budget, I set out in-house, freelance and project costs side by side.

What to look for

• Live work you can click, not only static mockups.
• The states behind the hero screen: the empty, error and loading versions.
• Code they wrote, and their reasons: a component, its props, how it handles focus.
• A design system they set up or kept alive, and how a change reached both Figma and code.
• Accessibility they can show you with a keyboard, live.
• Clear writing: a pull request description or a short decision note.

Questions to ask

1. Show me something you designed and built. What changed between the Figma file and the code, and why?
2. Walk me through every state of this screen. Which did you design first?
3. How do you keep tokens and components in step between Figma and the codebase?
4. Here's a component an AI tool generated. What would you change before merging it?
5. How do you test a dialog with a keyboard and a screen reader?
6. Tell me about a detail you cut because it cost too much to build.
7. How would you design an agent that changes data on a user's behalf?

Good answers are specific and a little opinionated.

A design engineer job description you can adapt

What you'll do: design and build interface features end to end; own the design system in Figma and in code; prototype interactions in the browser; meet WCAG 2.2 level AA; review interface code, including AI-generated code, before it ships.

What you bring: shipped work with live links; strong HTML, CSS, TypeScript and React; fluency in Figma; accessibility practice; clear writing.

The first thing I check in a new codebase is how many kinds of button it has. It tells me quickly whether a design system exists or only screens do.

A project starts with a free 30 minute intro call, then a written scope and one fixed quote for the whole project, with no retainer and nothing billed by the hour. We run weekly design sprints in Figma, with a written update in Slack every 48 hours and a review call each week. My team builds web apps and front ends in TypeScript, React and Next.js, and iOS and Android apps in React Native or Flutter, using AI coding tools where they save time. I'm in Dhaka (UTC+6) and work Sunday to Thursday, with evening calls from 7 to 10 pm Dhaka time for the Americas. There's more on my background and the team I lead.

If you're unsure whether you need a design engineer, start with the gap. Open your Figma file and your live product side by side, list where they disagree, then ask who owns that list. If the answer is nobody, that's the job.

Closing that gap is what my design engineering work with founders is built around: one person accountable from the first frame to the release, with a senior team beside me. Bring the Figma file and the repository to the intro call, and I'll tell you plainly what I'd fix first.

Is a design engineer the same as a UX engineer?

Mostly, yes. Both describe someone working where design meets front-end code, and Maggie Appleton lists UX engineer, UI engineer and front-of-the-front-end engineer among the overlapping titles. Names vary by company more than the work does, so when you hire, read the portfolio rather than the label.

Does a design engineer need to write production code?

In my view, yes, or code a production team would accept after light review. Someone who only prototypes is closer to a product designer who codes. The role's value is the design surviving into the shipped product, which means working in the real codebase, with its components, tests and review process.

What tools does a design engineer use?

Figma, a code editor, Git and the team's front-end stack, which for my team is TypeScript, React and Next.js. Many add a component workshop such as Storybook, a screen reader for testing and AI coding tools for first drafts. Habits matter more than tools: one shared system, and a review before anything merges.

Can one design engineer replace a product designer and a frontend developer?

For a startup's first product, often yes, alongside a back-end engineer. As the product grows, research, product strategy and complex application logic each need dedicated people, and the design engineer moves towards the design system and the hardest interactions. Nobody can do deep user research and build every screen at scale.

What should a design engineer's portfolio show?

Work you can open in a browser, not only images. For each project, look for the problem, the states beyond the main screen, a component with the code behind it, and what they cut and why. Accessibility and design system work are strong signals, and a walkthrough of private work is fine.

Is design engineer a real job title or a passing trend?

It's a real title with a short history. Vercel described it as a new role in March 2024, and Appleton's collection from the same month shows people at several product companies doing the work in public. The need underneath, someone who owns the gap between design and code, was described years earlier.

I read every source below on 7 October 2026. The search notes come from Google's suggestions, read that day. I found no reliable source for who first used the title, and no primary, dated salary source for it, so salaries are left out. The diagram shows how my team works, not a standard.

• CSS-Tricks, Chris Coyier, The Great Divide, 21 January 2019, read 7 October 2026: css-tricks.com
• Brad Frost, Front-of-the-front-end and back-of-the-front-end web development, 16 February 2021, read 7 October 2026: bradfrost.com
• Maggie Appleton, A Collection of Design Engineers, 11 March 2024, read 7 October 2026: maggieappleton.com
• Vercel, Design Engineering at Vercel, 29 March 2024, read 7 October 2026: vercel.com
• W3C, WCAG 2.2, Recommendation of 12 December 2024, read 7 October 2026: w3.org
• W3C WAI, What's New in WCAG 2.2, updated 5 October 2023, read 7 October 2026: w3.org
• W3C WAI, ARIA Authoring Practices Guide, read 7 October 2026: w3.org
• MDN Web Docs, prefers-reduced-motion, read 7 October 2026: developer.mozilla.org
• Design Tokens Community Group, Design Tokens Format Module 2025.10, read 7 October 2026: designtokens.org
• Design Tokens Community Group, first stable version announcement, 28 October 2025, read 7 October 2026: w3.org
• Figma, Code Connect introduction, read 7 October 2026: developers.figma.com
• Figma Help Center, Guide to the Figma MCP server, read 7 October 2026: help.figma.com
• Stack Overflow, 2025 Developer Survey, AI section, read 7 October 2026: survey.stackoverflow.co
• Google PAIR, People + AI Guidebook, Explainability + Trust, read 7 October 2026: pair.withgoogle.com