Design Engineer

Handing a design over and waiting for it to be built always leaked somewhere. Anything expressible as a number — a color value, a margin — survived the trip. Everything that resisted being written down as a number came out different: how fast a button shifts color under the cursor, how a list moves as it expands, whether text that overruns its container wraps or gets cut off.

None of that fits in a design file. A design file is a still image, so it can't show motion, and it usually contains one screen where everything went well, which means the case with very long text isn't in there at all. So Noa would write "make this smooth, maybe 0.2 seconds," Theo would build his best reading of it, Noa would look at the result and explain again in words. Each round took half a day, and after three rounds it was still a little off from what she had in mind.

The spread of design systems, which name values so design and code can share them, made the gap sharper. A system that exists only inside the design tool isn't worth much; the same values have to exist in code. Keeping the two sides aligned is neither drawing screens nor building features, so it belonged to nobody. The design engineer role collects that leaking work into one person, and it works by removing the handoff rather than improving it.

More than half the day goes into writing code, and the rest into design work and discussion. The difference is that the code produces the material screens are made from rather than the features themselves.

1. Building components — buttons, inputs, and the other pieces that appear across many screens get written in code and added to the component library. The bulk of the effort isn't the normal state, it's everything else: disabled, loading, text past twenty characters, and nothing to show at all.
2. Keeping values in sync — the names attached to colors and spacing have to point at the same values in the design tool and in the code. Those names are design tokens, and the day one side changes a value without the other following is the day the system splits in two.
3. Building the motion — interactions that can't be settled by description get built as something that actually runs. Making three versions at different speeds and putting them side by side settles the question faster than another meeting about it.
4. Checking the result — implemented screens get compared against the design, and the gaps get found. Problems like every margin landing four pixels off are often caught automatically rather than by eye.
5. Sitting in the design conversation — being in the room where screens are decided means the cost of building something can be said at the time. A layout that needs a value the product doesn't store yet is cheapest to learn about right there.

Not all five happen daily. On a team standing a system up for the first time, items 1 and 2 take the whole day; on a team whose system is settled, items 3 and 5 grow.

They sit next to two groups. On one side are the people deciding what the screen should be, usually a UX designer or a product designer. On the other are the engineers adding features on top of those screens. This role spends more of its time with the first group but follows the second group's rules for merging code.

Friction lives in the overlap. Two people now touch the same front-end code, and without an agreed boundary they edit the same file in opposite directions. The common split is components versus screens: shared components belong to the design engineer, while the screens assembled from them and the data behind those screens belong to the engineers. A tool like Storybook, which renders components in isolation so each state can be inspected, makes the boundary visible and the agreement easier.

Reporting lines go one of two ways. Inside the design team, the person naturally attends design sessions but drifts out of technical discussions; inside engineering, the reverse. Below about fifty people there's usually only one of them anyway, so what matters is which meetings they attend rather than whose org chart they appear on.

"I think we need a design engineer on this one."

The question can't be settled from a static design — something has to be built to know.

"I'll keep the tokens matched on both sides."

Making sure the design tool and the code hold the same values.

"I built three versions, so take a look and pick one."

A discussion that was happening in words is now three running screens.

At Pagedeck, changing how the document list sorts turned out to be this role's kind of problem. Noa wanted the items to visibly travel to their new positions when the order changed, and no design file could express that motion. After the second meeting where she drew the path in the air with her hand, the approach changed.

The design engineer built three versions running in a real browser, and Noa, Theo and Mia clicked through the same screen and picked one. It took thirty minutes and the chosen version stayed in the code that day. Theo handled only the part that fetches the data behind the list.

The most common mistake is reading the title as another name for a designer who knows some code. Two fields appear in the name, so it's easy to read one of them as a side skill. In practice this is a role that writes code which ships, held to the same standards for merging, testing and performance as any engineer's. Hire for the side-skill version and the designs come out well while the code never merges, so an engineer rewrites it — and the handoff the role was meant to remove comes straight back.

The second mistake is assuming that doing half of each means being mediocre at both. The value of the role isn't the average of the two disciplines; it's the set of problems that only appear between them. Timing of motion, layouts that collapse once real text lengths arrive, shadows that look right in the design tool and can't be produced in a browser. Two specialists can each be excellent and these still fall into the space between them, and adding meetings rarely surfaces them.