Design engineering
Design engineering is the seam
Same tools, often. A different outcome. Thirty minutes.
Christoph Hellmuth ยท Design Engineering Studio
Introduce yourself and the job in one breath. I am Christoph Hellmuth. I run a design engineering studio. I have spent sixteen years in product design, systems, and code. I speak both Figma and the repo.
This talk is for people hiring this role, and for people who are doing the work under a different title. Front-end engineer. Product designer who codes. Design systems lead. The title is less important than the outcome.
The outcome is: design intent survives handoff, at a size where you can no longer walk over to the person who drew it.
We will separate the role from front-end delivery, look at the seam, then talk about how to hire it or become it. Questions at the end.
Do not open with a definition from a blog. Open with the next line.
The point
Same tools. A different outcome.
React, TypeScript, and a well-used Figma file. The question is what still matches in production.
Put the tools on the table so nobody thinks you are inventing a priesthood.
A design engineer often uses the same tools as a strong front-end engineer: React, TypeScript, Tailwind or whatever the repo actually uses, Figma on the other side. A strong product designer may use those too. The overlap is real. I am not here to rank people.
The outcome is different. Front-end delivery asks: did the feature ship, does it work, is it fast enough, is it accessible. Those questions matter. I want them answered. Design engineering asks an extra one: when the tenth squad builds the next screen, does the intent still hold. The spacing, the states, the names, the behavior under error. Not a screenshot match. A decision that is still true.
If you only staff for features, you will get features. The system will be whatever duplicated along the way. That can be fine at five people. It gets expensive at twenty, and it gets political at eighty.
Say the line I use: the craft is business and syntax. I led Aurora at Nord, used by dozens of teams and millions of users. The work was reducing friction so those teams could scale, govern, and ship. Pixels were part of it. They were not the job description.
Then the photograph. Let it land before you define the role further.
The page is assembled by hand.
A composing room. The page is not a picture of a page. Someone sets it, from a case, under a measure.
Public domain. Say: production UI is set, not traced. If the only instruction is a picture, the person setting type will make reasonable choices that are not your choices. Design engineering is how the measure gets into the room where the page is assembled.
Short. Then who this is for, so the rest of the talk has a listener.
This room
You are hiring the seam, or you are standing in it.
The job shows up when design and engineering each wait for the other.
Name the two listeners.
If you are a head of design or a head of engineering, you have a gap. Specs go over a wall. Implementation comes back almost right. The retro blames communication. You hire another designer or another front-end engineer and the wall gets a fresh coat. The seam is still empty.
If you are the person who already lives in the gap, you are tired of translating. You redraw the component so engineering can build it, or you fix the component in code so design can see what is real. You are doing design engineering. The organization may be calling it something else, and it may be treating it as heroics.
Either way, the goal of this talk is to make the work legible enough to staff, and concrete enough to practice. Not a manifesto.
Products I have helped design reach a lot of people. The homepage figure is 250 million plus users, across the work, not a claim that one screen has that many. I say it so the seam is not a boutique concern. It shows up in large products and in a team of fifteen. The mechanism is the same. Intent has to cross.
Agenda next, then the distinction.
Thirty minutes
Three parts. Then a way to hire.
- 01Not a nicer front-end
What the role holds, and what it refuses.
- 02The seam
Names, states, and a review both sides attend.
- 03Staff it
What to ask, what to look for, what good looks like this quarter.
Read it. Promise you will not spend the half hour on org charts. One owner, a door, and proof in the repo. The governance talk goes further on adoption. This one is about the person and the practice.
Move.
Part one
Not a nicer front-end
Delivery ships the feature. The seam keeps the next feature honest.
Say it without insult. Some of the best front-end engineers I know already do this. The failure is expecting every feature engineer to also be the steward of the system, without time, and then being surprised when they are not.
Advance to the pair.
The split
What each job is answerable for.
Front-endThis feature works
Correct, fast, accessible, in the product, this sprint. A local exception can be reasonable.
Design eng.The next feature still matches
Names, states, tokens, and a component the tenth screen can use without a private dialect.
Walk both columns with respect.
Front-end, done well, is a deep craft. Performance, rendering, data, accessibility, the edge cases of one flow. I do not want design engineers who look down on that. I want them to be good at it, and then to ask a second question before they merge: did I just create a private dialect.
Design engineering is answerable for the dialect. The button the next squad will find. The token names. The focus state that was designed, not inherited from the browser. The doc that is true because it sits next to the code. The no, when a screen wants a one-off that should be a variant or should not exist.
A practical test. Look at a pull request. A front-end review asks if the feature is correct. A design engineering review also asks if a hard-coded value should have been a token, if a new component is a cousin of an old one, and if the states match the ones design named. If nobody is asking the second set, the seam is unstaffed. The feature can still be excellent. The system gets a little worse. That is the tax, one merge at a time.
Aurora is the scaled version of the right column. Dozens of teams could not each be the steward. Someone had to make the shared parts real, in the file and in the repo. At a smaller company the same column might be half of one person's week. Size the time to the number of squads, not to a fantasy platform org.
Land: hire for the right column if the left column is already covered and the product is drifting. Do not hire a design engineer to be a ticket-taking front-end, and do not hire a front-end and hope the system appears after hours.
What I hold
The work, when it is real.
- 01The contract
Names that mean the same thing in Figma and in the theme.
- 02The part
A component with states, built where the product can import it.
- 03The proof
A screen in production that uses the part, not a sandbox that only the team has seen.
- 04The no
A fourth button, a detached frame, a hex in a feature folder. Sent back with a path.
Four holdings. This is the job, more than any tool list.
The contract: I go deep on this in the tokens talk. Here, say that if you cannot point to matching names, you are still translating by meeting. Translation does not scale.
The part: primitives, then compositions, then features. A button is a primitive. A form field with label, hint, and error is a composition. A billing form is a feature, and it should be mostly composition. If feature code restyles primitives, the boundaries are wrong. Draw those boundaries so squads do not fork into a junk drawer.
The proof: Storybook is a proof, not the system. I want the component on a surface a customer touches. A library with perfect stories and zero imports is a folder. Say that plainly. I have seen the folder.
The no: this is the part organizations forget to authorize. If the design engineer cannot send a one-off back, they are a service desk. Give them the authority, and give squads a door so the no comes with a how.
Share credit where it is due. On a system, I led, and the teams shipped. Say "I led" for Aurora. Say "our team" when the work was a team. Do not perform solo heroics. The seam fails when it depends on one person's nights.
If someone asks about accessibility here: it is not a separate slide you bolt on. Focus, name, contrast, and the disabled state are part of the component. An audit in Figma that never reaches the repo is a poster. The role holds the path from the finding to the token or the component.
Type in the case. Press in the room.
The case and the press are in the same room. That is the whole org design lesson I will offer.
Public domain. Say: if the people who name the type and the people who run the press do not share a room, even a weekly one, you will get beautiful cases and sloppy pages, or fast pages and an empty case. Design engineering is the person who can stand at both, and who builds the habits so others can too.
Do not turn this into a co-location sermon. Remote works. The shared room can be a review with the component open in both tools. The failure is separate backlogs that never show each other the part.
A scale you can borrow
Dozens of teams. One system.
Aurora at Nord. Millions of users. The work was friction, not a poster.
Give the proof without a case-study performance.
I led the Aurora design system at Nord. Dozens of teams, millions of users. The point of saying so is not prestige. It is that the problems people treat as personality problems, "design and eng do not talk," become structural at that size. You cannot Slack the answer. The answer has to be in the component.
What I actually did, in language this room can reuse: made the shared parts real, kept the names boring, pushed decisions into tokens and components, and spent time on adoption. A system nobody imports does not count. I would rather a small set used everywhere than a wide set used in the sandbox.
A second proof, different shape. At Flyeralarm, a systematic correction cut reclamations by about 90 percent. That was product and UX, not only a component library. I bring it up so design engineering does not get framed as a styling guild. Sometimes the seam is an error that the product should correct the same way every time.
And a third, small. Lighthouse from 34 to 77 on a project, partly because one-off CSS gave way to shared structure. Performance was the measurement. The craft was the deletion of special cases.
Three proofs, then stop. If you stack more, it sounds like a reel. Tell them the pattern: repeated work, made identical, measured.
The unsexy screen is next, because that is where this job earns its keep.
Where the job earns it
The unsexy screen is the product.
Settings, errors, empty states, the table with the bad data. That is the system.
Design culture likes the first-run moment. The system is proven in the screen nobody puts in the case study. Settings. The error that happens on a Tuesday. The table with twenty states of missing data. The disabled button that still needs a reason.
If your design engineer only polishes the marketing page inside the app, you hired a visual front-end. Useful, sometimes. Not the seam.
Ask them to pick the screen their support team can describe from memory. That screen should be built from the system, first. It has the states. It has the ugly cases. If the system cannot express it, the system is a costume for the happy path.
I like the phrase from the work: the unsexy screen is the product. Say it, then give one example from their world if you know it. If you do not, use a billing failure or a permissions empty state. Do not invent a client story.
Land: feature teams will always prioritize the new moment. The role protects the repeated moment. That is business, not taste. Repeated moments are where customers decide you are trustworthy.
One office. One kind of drawing.
Many desks, one kind of work. Public domain. The drawing convention is what lets a stranger sit down at a desk and continue.
Say: your component API is the drawing convention. Props with plain names. States called the same thing design calls them. A new engineer should continue the drawing, not invent a parallel sheet.
Into the seam itself.
Part two
The seam
Handoff is teamwork. The artifact has to help.
One sentence of framing. I do not believe handoff improves because the spec got longer. I believe it improves when both sides share a review, a vocabulary, and a part that exists in both places.
Go.
Practices
What I would install in a month.
- 01One shared review
Design and engineering, on the component, in both tools. Not a readout.
- 02States before decoration
Default, hover, focus, active, disabled, loading. Written down.
- 03Names that compile
The prop, the variant, and the token are words you can say.
- 04A production import
The part has to ship in a flow, or it is still a proposal.
This is the practice, small enough for a month beside feature work.
One shared review: thirty to forty-five minutes, weekly, one component or one flow. Both sides can reject. If only design talks, it is a critique. If only engineering talks, it is an implementation review. The seam is the overlap. Bring the ugly state, not the hero screen.
States before decoration: I want six, and I want them named. Hover is not the design. Focus is where keyboard users find out whether you meant it. Disabled without a reason is a dead end. Loading that shifts layout is a bug you designed. Write them before you argue about shadow.
Six states, one button. That constraint does more for consistency than a principle poster. If a state does not apply, say so. Do not leave a blank and hope.
Names that compile: primary is a weak name if you also have brand, main, and accent. Pick action. Use it in the prop if you can. Designers and engineers should not need a glossary.
A production import: choose the flow. Replace the local button. Delete the local CSS if you can. Screenshot the before and after for the people who fund the role. They need to see a merged pull request, not a library announcement.
Mention teamwork directly. Handoff fights are a teamwork problem before they are a tooling problem. The review is the ritual. The names are the language. The import is the trust, because engineering sees that design will meet them in the repo, and design sees that the repo is not a place their intent goes to die.
If the room builds mobile and web, say the seam includes both only when the decisions are truly shared. Do not force one component model onto two platforms to look tidy. Share the names and the states. Let the implementation be native.
States
Six states. One button.
If you design the happy path only, engineering will invent the rest.
Stay on this. It is the most concrete craft slide in the talk.
List them out loud. Default: the control at rest. Hover: a cue for the pointer, not a new layout. Focus: visible, not the browser's guess, and not removed because it is ugly. Active: the moment of press. Disabled: visually quiet, and programmatically true, with a way to know why if the reason is not obvious. Loading: the action was taken, and the control tells the truth while it waits.
I have watched beautiful buttons ship without focus, because the file did not include it and the implementer was matching the picture. That is the picture problem. The composing room will match what you gave them.
A design engineer draws the six, builds the six, or pairs until the six exist. They do not write "see hover" in a ticket and call it specified.
Accessibility lives here, in the work, not in a checklist at the end. Contrast on the label. The focus ring against both themes. The disabled control not disappearing for someone who needs to understand the gate.
Land: decoration is what you do after the states are true. If you start with decoration, the states become patches, and patches become the dialect.
Hands on the type.
Hands on the metal. Public domain. The craft is physical in this picture, and it is still physical in a repo: someone has to touch the component.
Say: a design engineer who only comments in Figma is a critic. A front-end engineer who never opens the file is guessing. The job has hands on both.
Do not linger. The business slide is next, so this does not stay a craft romance.
The business
Friction you can count.
Rework, tickets, a slow hire, a feature that waited on a translation.
Connect the role to money without a fake ROI formula.
What I ask leaders to count: pull requests that restyle something the product already had. Review hours spent on settled questions. Support tickets that are really inconsistent UI. Days before a new person ships a screen that looks like the product. Those are the same four buckets as the tax talk. Use them. A design engineer is justified when those numbers move, not when the library is large.
About 90 percent fewer reclamations is the sharp version, from Flyeralarm, and it came from a systematic fix. Use it if someone says craft does not have a business case. Then return to their numbers. You do not know their refund rate. Do not invent one.
Also say what the role costs. Time. A senior person who can do this is not a bargain hire, and they should not be stacked with a full feature quota and a system quota. If you give them both at one hundred percent, you will get features and a guilty slide about the system. Give the system a real share of the week. I would rather name the share, two days, than pretend it fits in the cracks.
The studio, if they ask what I do now: I help scaling teams fix this seam. Audit, foundations, a longer build, sometimes a fractional partner. You do not need to read the price list from the stage. The consult is the door. Get a free consultation. Thirty minutes. Honest either way.
Keep this slide in service of the role, not of the studio. The room should be able to staff it without you.
The press is the source.
The press is where the page becomes real. Public domain. In software the repo is the press. Figma is the case. Both matter. The customer only receives what the press made.
Say: if the system lives only in the file, you have a prospectus. Design engineering is done when the press is setting from the case.
Into what I refuse, so the role has edges.
Edges
What I will not pretend this role is.
- 01A ticket queue for screens
If the backlog is only feature UI, you hired delivery.
- 02A Figma janitor
Cleanup without a path into the repo does not survive the next squad.
- 03An AI operator
Tools can draft. They do not own the name or the no.
- 04A brand studio
Identity matters. It is not a substitute for the component in production.
Edges protect the person you hire. Say each one as a kindness.
Ticket queue: they will drown, the system will not move, and they will leave. I have watched this. The title was design engineer. The calendar was Jira.
Figma janitor: organizing a file is useful for a week. If the repo does not change, you tidied a picture of the product.
AI operator: I use agents. I also know they invent steps. The planner and executor pattern is real for large UI: structure first, then tasks. The person still accepts the diff. First place at Into Design Systems in 2026 was a plugin that swaps mismatched components. It assumes you know which component is the right one. The role holds that knowledge.
Brand studio: a rebrand that does not pass through tokens and components will be a second inconsistency, on a deadline. The role can help the rebrand land. It should not be hired to invent a mood.
Land: write these edges into the job post. Candidates who want the seam will recognize them. Candidates who want a different job will self-select, which is a gift.
Part three
Staff the seam
A quarter, a review, a component in production.
Tell them the hiring section is also a becoming section. If they cannot hire yet, they can practice the month. If they can hire, the interview should look like the work.
Go.
This quarter
What good looks like in ninety days.
- 30One component, six states
In the file and in the repo. Same names. A flow uses it.
- 60The review is a habit
Both sides attended more than once. A one-off was sent back.
- 90A second squad imported it
Without a private fork. The door was used, not just described.
This is the scoreboard. Read it as acceptance criteria for the role, or for yourself if you are the role.
Day 30: one component. I keep saying the button because everyone has one. If the button is fine and the text field is the mess, do the field. Six states. Production import. If day 30 is a strategy deck, restart.
Day 60: the review happened, and it had a consequence. A no, or a yes that became a variant with a name. A review that never changes the system is a status meeting. Cancel it.
Day 90: someone who does not own the system used it, or contributed through the door. Adoption is the product. If only the design engineer imports the component, you have a personal library.
Staffing shape: one person can do this at a modest scale if feature work is actually reduced. Two, a designer and an engineer who both touch the seam, is often healthier than a lone translator. I have been the lone person. It works until holiday. Write the decisions down so the work survives you.
What I would look for in a hire, in the next slide, should match this scoreboard. Do not interview for trivia and then expect this quarter.
If they already have a design systems team that is separate from product, ask whether that team can ship a change into a product repo this month. If they cannot, they are advisory. Advisory can be wise. It is not the seam until the press moves.
The interview
Do not ask them to invert a binary tree.
Put a real component on the table. Ask what they would refuse.
Practical hiring, because this is where companies waste the search.
Give them a component from your product, with the Figma and the code if you can. Ask them to walk the states. Ask where the names diverge. Ask what they would delete. Ask how they would get a second squad to use it without a mandate that fails. You will learn more in forty minutes than from a puzzle that tests whether they memorized an algorithms course.
Look for someone who has shipped, not only specified. Look for someone who can talk to designers without translating them into tickets, and to engineers without dismissing the file. Look for a no they are proud of, and a compromise they do not romanticize.
A warning: the market uses this title loosely. Read the portfolio for a system in production, not for a concept library. Ask who else was in the work. I led Aurora. I did not draw every screen that used it. A candidate who claims the whole product alone is a risk. A candidate who can name the owners and the users is a better sign.
If you are becoming this person: pick the component, open the repo, and do the day-30 project in public. The title can follow the proof. Do not wait for permission to learn the seam, and do not vanish from your feature team without an agreement. The agreement is the time.
Fifty clients and sixteen years are the long version of practice. You do not need that to start. You need one component that is true on both sides.
A row of the same machine.
A row of looms. Public domain. The shed works because the machines match. One custom loom in the corner becomes a specialist's secret.
Say: squads are the row. The component is the machine. Design engineering keeps the row in the same setup, and knows when a truly different machine is warranted.
Then the close. You are near the half hour. Do not add a new framework.
Honest next steps
Name the seam. Give it time. Ship one part.
If you want the gap read with you, the consult is free.
Monday: write one paragraph that says what the seam is accountable for this quarter, using the ninety-day scoreboard. Put a name next to it, even if the name is yours. Put hours next to it.
If the paragraph is impossible because the calendar is full of features, you have learned something. You are choosing the tax. Say that to leadership with the four buckets, not with a plea for craft.
The consult: Get a free consultation. Thirty minutes. No pitch. I will tell you if you need a person, a foundations sprint, or just a review habit you can start without me.
Stop. The next slide is the line.
Design Engineering Studio
Intent has to survive the handoff.
Staff the seam, or keep translating by meeting.
christophhellmuth.com
Read it. Pause.
Questions. If the room is hiring, offer to look at a job post after. If the room is practicing, offer the component test: six states, one button, in both tools, this month.
Do not recap all three parts.
Questions
Where does intent die today?
In the file, in the pull request, or in the review that never includes both.
Use the question. Listen for which of the three deaths they describe, and answer that one, not all three.
If it dies in the file: the states are not drawn, or the names are private. Start there. Do not buy a tool.
If it dies in the pull request: the implementer cannot find the part, or is rewarded for local speed. The door and the review.
If it dies in a review that is design-only or eng-only: combine them once, on one component, and see what happens. Handoff is teamwork.
A question you may get: is this just a staff engineer who cares about UI? Sometimes yes. If that person has the time and the authority, do not obsess over the title. If they are accountable for uptime and architecture across the whole platform, they will not also hold the button. Name the seam anyway.
Another: should designers code? They should be able to read the implementation of the shared parts, or pair on it. Not everyone must ship production React. Someone at the seam must. If no designer can read a component and no engineer will open Figma, you do not have a seam. You have a wall with polite tickets.
End on the line if you need a last beat. Intent has to survive the handoff.
You should be at thirty minutes, including this, if you kept the photographs short and did not take every proof.