What does a product design engineer actually do?

Key idea 1 of 7

The handoff did not move; it dissolved

For years the shape of a design job was a document that went somewhere else. You made the file, somebody built from the file, and the distance between the two was where the quality leaked out. AI coding tools moved that line: a designer can now build the thing, verify it and stand behind it. This is about what the work looks like once you are standing on the far side of it.

The short version: there is no far side. A design engineer is a designer whose deliverable is the thing itself, in the repository, next to everyone else’s. The judgment is the same judgment. What changes is that every decision now has evidence attached, because it is code that runs, and a colleague can open it.

Key idea 2 of 7

The component is the deliverable, and it lives in one place

In a product codebase the unit of design is a component: a button, a data table, a status line, a card. In React it is a function that takes properties and returns markup, and in TypeScript the properties are typed, which means the contract between design and engineering is a list the compiler reads rather than a note in a Figma frame. A button that can be primary or ghost, disabled or not, is a button whose four states are four values in one file.

The showroom for that file is Storybook: every component, every state of it, rendered on a page a designer can open without running the product. It is the design system’s own site, generated from the system, and it is the single artifact a design engineer most clearly owns. If the story for a component is wrong, the component is wrong.

It replaces

• The spec that described the states in words
• The redline that measured the padding by hand
• The second copy of the button, drawn again in another file
• The question “is this the current version?”

It keeps

• The judgment about what a button is for
• The eye for a corner that reads as a lozenge at that size
• The argument for why the disabled state is quieter, not lighter
• The person who says no to a fifth variant

I run this today at one scale, not two. This site is a design system with three token files and a component set written in plain HTML and CSS, with Node scripts standing where a build would. React with TypeScript and Storybook are the same idea at team scale, with a compiler and a showroom doing what my checks and my comments do here, and they are the part of the stack I am growing into rather than the part I have run for years. That distinction matters, and I would rather say it than have it discovered.

Key idea 3 of 7

Tokens flow one way, from a file everyone can read

A design system that lives in code has one source for every value: a file of tokens, usually JSON, that says what --color-accent is and what --space-lg is. A tool such as Style Dictionary turns that file into whatever each platform needs: CSS custom properties for the web, constants for iOS and Android, a table for the documentation. Tokens Studio does the same from inside Figma. The direction is what matters. The file is upstream of everything, so parity between the design and the code is not a review step; it is the only way the values exist.

The vocabulary the design-engineer postings use comes straight from this file. A primitive token is a raw value with a plain name: a green, a size. A semantic token says what the value is for: the accent, the text on a dark ground, the inset of a panel. Semantic tokens point at primitives, components point at semantic tokens, and nothing points at a hex code. Change the green in one place and every button, badge and link moves with it, on every platform, in one pull request. The file has a third reader now: an AI coding tool generates from whatever the system made legible, and a token it cannot find is a hex code it will invent.

This is the part of the job I have done longest, by hand and at enterprise scale, and it is the part where the tooling changes least. My color spec tabulates every ink on every ground with its measured ratio; a token file does the same in a form a build can read. The discipline is identical. What the pipeline adds is that the discipline stops depending on anyone remembering it.

Key idea 4 of 7

A pull request is a design review with the evidence attached

A pull request is a proposed change to the codebase with its reasoning written above it and its difference rendered below it, and it is where a design engineer spends more of the day than any tool with a canvas. Reading a diff is how a designer sees what actually shipped rather than what was intended. Opening one is how a designer proposes a change that engineering can accept with a click instead of scheduling a meeting to describe.

The postings say “comfortable participating in pull request reviews,” and at nine in the morning that means: read the change, open the story, press the states, and leave a comment on the line rather than in a channel. It also means being reviewed. A component I wrote gets read by an engineer who sees the failure modes I do not, and the review is not a gate the design has to pass; it is the second pair of eyes the design has been missing.

Key idea 5 of 7

The prototype is a branch, not a file

Here is the day, in order, for a change that begins as an idea rather than a ticket.

1. Briefthe problem in one sentence everyone recognizes
2. Storythe component and its states, in Storybook, before the product
3. Branchthe prototype, working, on real inputs
4. Reviewan engineer reads the diff; the design gets its second pair of eyes
5. Shipthe merge is the handover, and there is no other

The tools that changed this are the ones that write code from a description: Claude Code in a terminal, Cursor in an editor. They took the mechanical barrier out of the middle of that list. A working prototype on a branch used to be a week of an engineer’s time or a week of my own evenings; it is now an afternoon, and the afternoon is spent on the decisions rather than the syntax. The dispatch cockpit on this site is the worked example: a comparison, an override question and a refused assignment, all rendered from real code, and every one of them a decision I could show rather than describe.

What those tools do not take out is the judgment. The posting that says a design engineer should use AI without relying on it has the emphasis right. The prototype is real because I can read what it does, not because something wrote it quickly. The branch is where that reading happens, and the pull request is where it is shown.

Key idea 6 of 7

Motion is code you can review

The craft the postings name most precisely is motion: easing curves, spring physics, transitions that can be interrupted halfway and reversed without a stutter. In a design tool those are a demo somebody plays in a meeting. In the codebase they are a handful of values in the token file and a component that reads them: a duration, a curve, a spring’s stiffness and damping. Framer Motion, now simply called motion, does the physics for React; plain CSS transitions do most of the rest, and a motion spec of six durations and one curve covers a whole site.

The point is not that motion is easier to write in code. It is that motion written in code is reviewable. A transition can be opened in Storybook, played, interrupted, played again at a reduced-motion setting, and commented on by line. A spring that overshoots by a hair is a number a colleague can change, and the change is a diff. That is what “design owns quality end to end” means in the one part of the interface where quality used to be unownable, because nobody could point at it.

Key idea 7 of 7

The checks are part of the design system

A design rule that is not a script is a wish. Contrast floors, type scales, token coverage, whether a rounded surface carries a partial border: every one of those can be measured on the rendered page, and a design engineer’s last responsibility is to make sure they are. In a team codebase that means visual regression tests, with Chromatic or Playwright taking a picture of every story and refusing a pull request that changed one without meaning to; accessibility checks, with axe running in the pipeline rather than in a report at the end; and a token check that fails the build when a component reaches for a value the system does not have.

9

checks; four of them render every page in a real browser and measure what is there

5,774

colors a reader can see, each measured against its floor, at rest, before anything ships

14

steps on the type scale, and every rendered size at four widths is one of them

I built that set for this site because the rules were written down and nothing held the pages to them, and the first pass found a caption shipped at 3.88:1 and a hover at 1.29:1 that no eye had caught. The same instinct scales: a design engineer is the person on the team who thinks a design rule is a test, and writes it as one.

So the honest map of the job, for me, has three regions. Tokens, systems, accessibility and the checks around them: that is the work I have done longest and the part I would run on day one. Prototypes on a branch, pull requests, motion as reviewable code: that is the work I do now, on this site and on the prototype, and the part I would be fluent in within a quarter. React with TypeScript and Storybook at team scale: that is the part I am growing into, with the same tools that made the prototype possible, and I would rather write that sentence here than have someone else write it about me.