Design Engineering
What design engineering is, how it's changed, and where it's going
The environment in which we build software is changing, and as a result so is the design engineering role.
Historically, design engineers often sat between design and engineering. They prototyped ideas, built design systems, preserved interaction details, and helped reduce the translation loss between intent and production.
Today, especially at high growth startups, the expectation is moving beyond translation. Designers are learning code. Product engineers are developing stronger product instincts. Coding agents are reducing implementation friction.
The valuable question is shifting from "Can you bridge the gap between intention and implementation?" towards "How much of the gap can one person own?"
Design engineering is less about sitting between functions and more about combining the parts of those functions that let one person ship beautiful product.
The Spectrum
Design engineering is best understood as a spectrum, not a single role. Historically it sat closer to design: prototyping, interaction work, design systems, and preserving product intent through implementation. This was the design engineer who helped the team ship it. Increasingly it sits closer to engineering: production code, product decisions, and end-to-end ownership. This is the design engineer who ships it themselves.
Both are design engineering. But the role isn't standing still. The center of gravity is moving toward the engineering end, toward people who can own more of the path from intent to implementation, not just bridge it.
At Vercel, the role already carries real ownership over production quality, product taste, and the systems that help teams ship. At Gumloop, it sits further still: owning features, making product decisions, and turning intent into shipped product.
Why Design Engineering Exists
In traditional product teams, there is a process between what is imagined for the product (intent) and what gets shipped (implementation).
The further intent has to travel, the more likely it is to change. Technical constraints, time constraints, and translation loss can push intent and implementation far apart.
Design engineering compresses that process by putting more of it under one person. Instead of passing intent through separate product, design, and engineering handoffs, a design engineer carries the original judgment all the way into what ships.
What Design Engineering Really Is
The ability to turn intuition about what makes a great user experience into shipped product.
A design engineer could likely hold their own as a designer, or an engineer. They might be exceptional as either, but they are exceptional because they have both abilities.
That combination matters more as software becomes easier to produce. When anyone can build the thing, the version that feels best wins, and people with strong taste and the ability to ship have more leverage than ever.
This shifts what's valuable. Deliverables that don't move the product forward matter less. A process artifact that never gets used, or a wireframe that doesn't help the team ship, counts for less than finished product.
This is where taste becomes important.
Taste?
Taste is not just a matter of aesthetics. Taste is a combination of, visual taste, interaction taste, UX judgment, product intuition and more. A person could be strong across several of these, or exceptional at just one.
Rick Rubin has a useful way of explaining this. The exchange often gets shared as a vibe-coding meme, but it effectively gets at what taste is:
I have no technical ability. And I know nothing about music. [...] I know what I like and what I don't like. I'm decisive about what I like and what I don't like. [...] The confidence that I have in my taste, and my ability to express what I feel, has proven helpful for artists.
Taste matters on its own, but in design engineering it becomes useful when paired with decisiveness, communication, and the ability to ship.
What a Design Engineer Actually Does
Intent
Product Decisions
Experience (UX)
UI Design
Design Systems
Interactions
ImplementationFrontend
At Gumloop, we're building an AI automation operating system: a place where technical and non-technical teams can build agents, connect them to company knowledge, deploy them in Slack, email, and the web app, and trust them with real work. That trust takes a lot of product surface area. We own the pieces enterprises need to roll AI automation out to thousands of people at once: observability, permissions, user management, credentials, cost controls, hosted MCP servers, and more.
That is the environment a design engineer steps into here. Gumloop is wide by nature, and every part of it needs to feel understandable, powerful, and safe. The role is not to polish one narrow corner. It is to move across the product, find the places where complexity feel uncomfortable or unclear, and ship the interfaces that make it all feel coherent.
If this sounds like an environment you thrive in, please email me: marcelo@gumloop.com
Day-to-day
A design engineer at Gumloop turns ambiguous product problems into shipped product. They reason through the UX, design the solution, build the frontend, and work across the stack, or partner with other engineers, when needed.
The work changes week to week, but the shape is consistent:
- Design and build core product surfaces
- Own features from early product thinking through implementation and iteration
- Improve the design system, component library, and patterns other engineers use
- Sweat the last 20%: accessibility, performance, responsive behavior, motion, empty states, and edge cases
Assessing Design Engineer Profiles
This is a rare profile, so I look for evidence that someone has already proved they can ship with high taste:
- Products they built end to end, used by real people, that solved a real problem
- Personal projects, prototypes, or a personal site with clear craft and point of view
- Public work that shows care for details: primitives, interactions, motion, accessibility
- Artistic or multidisciplinary taste outside a standard product-design path
None of these prove someone is great, but together they point at taste, judgment, and the ability to make both real in product.
Where Do You Sit?
Product designers will be expected to prototype more of their work. Not necessarily to become production engineers, but to move closer to implementation, or to produce artifacts that better communicate intent to the people building it.
Product engineers will move in two directions. Some will move closer to design engineering and take on more product-facing ownership. Others will move deeper into full stack engineering, focusing on systems where precision matters more than finesse.
At Gumloop, we are hiring for that convergence. The most exciting people are increasingly difficult to categorize, which is how you end up with titles like design engineer. Once someone can:
- Understand users
- Make product decisions
- Design interfaces
- Write production code
- Ship independently
Their title matters a lot less than their capabilities.
I believe design engineering sits at the center of that convergence. Eventually, it may just be what we call someone who can build product end to end. For now, it is the best label we have for the kind of person we want here.