Design Engineering: the space between intent, interface and product
Why the space between imagining an experience and shipping it to production matters more, and what changes in practice for design and engineering.
9 min read
The environment in which we build digital products has changed. Design tools evolved, front-end work accelerated and coding agents reduced part of the implementation effort. Boundaries between Product Design, design systems and interface development became less rigid.
Design Engineering gains traction in that context. Not to merge design and engineering into one role, but because the space between imagining an experience and shipping it to production became more demanding and more exposed.
For a long time, that space worked as a bridge: design documented intent, engineering interpreted and implemented. The more a decision has to travel between steps, the more it dilutes along the way.
Design Engineering exists to shorten that path.
This essay builds on Marcelo Chaman's discussion of Design Engineering and offers my reading from Product Design, design systems and interfaces for technical products.
Less handoff, more ownership
Handoff still organizes collaboration, but it exposes a limit. Empty states, errors, responsiveness, accessibility, performance and real data rarely fit in a static screen or a Figma comment. These details define whether a product feels trustworthy.
Design Engineering expands responsibility over that layer. Instead of only explaining intent, it helps carry it closer to the product: by prototyping, implementing or creating components and patterns that let teams build with more consistency.
Before and after the handoff
Compare how intention travels in a traditional process versus a Design Engineering workflow.
Intention
A clear experience goal is defined in design.
Documentation
Flows, screens and specs are prepared for another team to build.
Handoff
Intent is translated into tickets, comments and static artifacts.
Intention often weakens here
Interpretation
Engineering interprets gaps, ambiguities and missing states.
Intention often weakens here
Implementation
Delivery happens under schedule pressure, often without full context.
Delivery
The shipped product may diverge from the original intent.
A spectrum, not a fixed role
Design Engineering is not a fixed point between design and engineering. It is a spectrum.
In some teams, the role sits closer to design: prototypes, UI, design systems and preserving details during implementation. In others, closer to engineering: production code, interface ownership and end-to-end delivery. What changes is how much this person influences or owns each step until what reaches the user.
Product Design
Leads product intent, problem framing, and experience decisions focused on user and business value.
Visual model adapted from Marcelo Chaman's essay on Design Engineering. marcelochaman.ca
What this role does in practice
This profile tends to work where experience and technology meet: turning ambiguous problems into working interfaces, building prototypes closer to reality, evolving reusable components and caring about delivery quality.
The work shows up mainly outside the prettiest screens of a case study: error states, breakpoints, accessibility, tokens, component variations and decisions that prevent long-term design debt.
At Azion Console, a technical product with high complexity, I saw this up close. With Console Kit, I worked to bring design system and front-end closer: components, icon libraries, code prototypes and documentation, in close conversation with engineering.
The goal was not to replace engineering, but to converse with more precision, anticipate friction and preserve experience quality between a design decision and what ships to production.
Responsibility map
Comparison between a traditional model and Vercel's model (speculated), showing which layers the role owns more responsibility across UX and production.
| Traditional ModelHistorical | VercelSpeculated | |
|---|---|---|
| Intent | Intent, Traditional Model: Not owned | Intent, Vercel: Not owned |
| Product Decisions | Product Decisions, Traditional Model: Not owned | Product Decisions, Vercel: Not owned |
| Experience (UX) | Experience (UX), Traditional Model: Not owned | Experience (UX), Vercel: Influences |
| UI Design | UI Design, Traditional Model: Influences | UI Design, Vercel: Shared ownership |
| Design Systems | Design Systems, Traditional Model: Shared ownership | Design Systems, Vercel: Owned |
| Interactions | Interactions, Traditional Model: Owned | Interactions, Vercel: Owned |
| ImplementationFrontend | Implementation, Traditional Model: Shared ownership | Implementation, Vercel: Owned |
| Other production work... | Other production work..., Traditional Model: Not owned | Other production work..., Vercel: Not owned |
Visual model adapted from Marcelo Chaman's essay on Design Engineering. marcelochaman.ca
Design systems as infrastructure
A design system should not be only a visual library in Figma. It needs to work as shared infrastructure between design and engineering: tokens, components, patterns, real examples and usage criteria.
When that layer is solid, it reduces rework and speeds up decisions. Design Engineering helps keep it alive as a system that evolves with the product, not as static documentation.
Profiles in convergence
Product Designers do not need to become production engineers, but understanding how interfaces are built changes how you design and collaborate. The conversation with engineering starts including trade-offs, systems and impact on experience, not only screen implementation.
On the other side, product engineers gain sensitivity to UX and interface decisions. That convergence creates professionals that are harder to categorize, and maybe that is what the term Design Engineer tries to name.
What becomes more valuable
Building software became more accessible, but the difference is not in producing any interface. It is in producing the right one, with clarity, consistency and intent preserved through real use.
Design Engineering points in that direction: less translation between thinking and doing, more responsibility over the experience that reaches the user. For me, the value is not in the title, but in connecting design repertoire, product judgment and technical understanding.
In the end, it may simply be the current name for an increasingly common skill: turning strong intent into a clear, viable and well-built experience.