What Does a Design Engineer Actually Do?
I came across the title “design engineer” only recently. It did not feel foreign. It overlapped, almost uncannily, with the work I have been doing for years.
So I decided to keep a series about figuring out what the job actually is. The first question is this one. What does a design engineer actually do?

What is a design engineer?
A design engineer is someone who designs a screen and builds that same screen in code. The “In software engineering” section of the Wikipedia entry for “Design engineer” describes it as a person capable of doing both the design work and the software development.
Maggie Appleton, a design engineer and writer, puts it more concretely.
Someone who stands squarely at the intersection of design and engineering, and works to close the gap between the two.
The work comes down to two things. Prototyping, and designing in code.
What do they do between designers and engineers?
They carry intent across. Product designers and UI/UX designers look at a screen through a designer’s eyes. Engineers look at the same screen in another language.
There is a moment when both groups finish a meeting in their own language and believe they have agreed. Then the build opens, and it is subtly off. I have watched this happen more than once. Spacing drifts by 4px, a loading state appears that was never designed, an animation ships at half its intent. Nobody was careless, and it still happens.
The design engineer stands in that space. Designer’s language for the designers, engineer’s language for the engineers. Translation is not swapping words. It is carrying over why that spacing, why that timing.
How has AI changed the job?
It let designers go all the way alone. Before, a shallow grasp of development meant hitting a wall at some point. Now a broad but shallow grasp is enough to solve the problem without borrowing an engineer’s hands.
You do not have to learn to code the way an engineer does. What you do need is to turn precise feedback and precise requests into language a machine understands. If you can name what is wrong and say how it should be fixed, you can push the work to the end.
The site this piece sits on was built that way. Design through code, alone, getting past each wall by explaining to an AI exactly what the problem was.
Why does the name matter now?
The grey zone was always there. “Designers who code” and “engineers who design” have been around for a long time. What was missing was a name for that grey zone as a role of its own.
If anything, AI pushed the focus back to the essentials. Judging what should be built and conveying it precisely came to matter more than fluency with any one tool. Once judgment and communication are the core, the border that separated designers from engineers stops carrying the weight it used to. That is where the name became necessary.
In short
A design engineer is a translator and a self-sufficient problem solver. Inside a team, the bridge between designers and engineers. Outside one, someone who makes a finished thing with AI as the tool. The two directions are not exclusive. They grow together in the same person.
Looking back at my years working as a designer, I had already been walking both. It just did not have a name.
In the next piece I will work through what capabilities a design engineer actually needs, and what tools and workflows the job runs on.
Source: Design engineer, Wikipedia