Three kinds of design engineers

People often reach out to me about a career in design engineering, and the first question is usually what we actually do. I find it hard to answer in one sentence. People with the same title might build product features, work on a design system, or make 3D and motion. Those are three jobs that need different skills, ship different things and get judged in different ways.

Design engineering has caught on over the last few years, but it's still a fairly new and niche role, and there isn't a shared understanding of it yet. It looks different at every company and on every team. Some job postings are generic and don't say what they want, and people thinking about the field can't tell whether it's right for them.

The way I see it, the title covers three different jobs: product, systems and creative.

What they share

First, what they have in common. Every design engineer works between design and engineering. They hold a designer's bar for quality and have an engineer's control over implementation. Day to day, the work falls into two kinds: designing with code, and solving engineering problems that are specific to design.

Product design engineer

Product design engineers serve end users. They usually sit on a product team and work with PMs, designers and engineers to turn an idea into something in users' hands: prototype, iterate, polish, ship. Roles that only prototype and don't ship belong here too, because what they work on is still the product experience. This is the most visible kind of design engineer right now, and the one people talk about most. I did this for a small part of my time at Mintlify and Wealthsimple.

Doing it well means a high-quality product experience and a short path from idea to users. The core skill is judging an experience against real data and real constraints: interaction details, states, edge cases, and how fast it feels.

There are two common ways it goes wrong. You slowly turn into an engineer who just implements UI without questioning it, or you keep making demos that never make it into the product.

Systems design engineer

Systems design engineers serve internal teams: designers, engineers and agents. They make what other people use to build the product: design systems, components, tokens, docs, design tools, and the agentic workflows around them. That was most of my time at Wealthsimple and my role at GitHub, and it's how I think of myself.

Doing it well means good DX, adoption, consistency, and making other people faster. A systems design engineer's impact is multiplied: one change shows up across the whole product.

The core skills are API design for abstractions, migration and maintenance, plus an understanding of the whole product: knowing which patterns are worth consolidating and which are one-offs.

One common failure is a system that's beautifully designed, that you're very happy with, and that nobody uses. Another is ignoring just-in-time and doing the work too early or too late. Too early means adding a pattern to the system before it has really emerged. Too late means trying to consolidate after the UI has already split apart.

Creative design engineer

Creative design engineers serve the brand and its audience. They make motion, graphics, 3D, WebGL, marketing pages, announcements and interactive storytelling. Plenty of creative developers do exactly this work under a different title. They tend to be very strong technically: of the three kinds, they go deepest on graphics, rendering and performance.

Doing it well means leaving an impression. People remember it, want to share it, and are struck by a product the first time they see it. The core skills are a feel for visuals and motion, and the technical skill to build them and make them run smoothly.

The common failure is work that's flashy but doesn't serve what it's meant to say. Form over substance.

Overlap and a primary type

Most design engineers have worked in two of the types. I've done both product and systems. At some startups, one person does all three. But most people have a primary type. It's what you're best at, what you find most rewarding, and how you get evaluated.

Type × domain

Beyond type, there's a second dimension: domain. AI, Android, iOS, legal, fintech, dev tools, games and so on. Type and domain are different things. Type is who you work for and what you make. Domain is the industry and context you do it in. So an AI design engineer isn't a new kind of design engineer. The domain just happens to be AI.

Domain knowledge is a real advantage. Within a type, fewer people can pick up a domain quickly and understand it deeply, and they're harder to replace. Your impact is biggest in a role that fits both your type and your domain.

Reading a job posting

A line like "bridge design and engineering" is true of all three types, so it doesn't help anyone figure out what a role is. When you read a design engineer job posting, try to find answers to these questions:

• Who does it mainly serve: end users, internal teams or the brand?
• What does it mainly produce: features, tooling or brand moments?
• How is success measured?
• Which team is it on, and who will you work with?

If a posting doesn't answer these well, the hiring manager or the team may not have figured out what the role is yet. That's not a red flag, but make sure you're comfortable with some uncertainty.