Design engineering as a discipline has surged over the past two years. It’s gone from a niche title at a handful of craft-obsessed companies to a role that nearly every product-focused startup is now trying to hire for. New tooling innovations have drastically changed the landscape: the barrier to building ideas has lowered, giving designers and engineers newfound capabilities to work across disciplines that used to be siloed.
The title itself also has a magnetic pull; it attracts people who are self-directed, curious, interdisciplinary, and love building things end to end. But as exciting as it is, it’s become one of the most notoriously difficult roles to hire for. “Design engineer” can mean wildly different things depending on the company, and there’s still no consensus on how to define it, find great talent, or evaluate it.
I’ve been in the design engineering space for more than three years, with early career stints across product, engineering, and design. This piece weaves insights from being in the field, conversations with founders about hiring design engineers, and peers in this role.
This is part one of a three-part series on hiring design engineers. In this piece, we’ll focus on defining the role. Parts two and three will cover how to find great design talent and how to evaluate them.
Disclaimer: this piece does not reflect the views of my current or past employers!
Defining the design engineer role
A common misconception is that a “design engineer” is exceptional at both design and engineering, but it more so describes an interest and ability to move between disciplines. The special value a design engineer brings is their ability to make cool stuff happen because they’re embedded in these two worlds. New interactions are built, ideas are brought to life, dots are connected between traditionally isolated teams, and it creates room for ideas that may never have emerged otherwise.
This framing draws on Emil Kowalski and Vincent van der Meulen’s thoughts on the space, both of which resonate deeply with my own experience.
Bridging together product, design, and engineering is incredibly powerful. From speaking with a few different early-stage AI companies, many describe the magic of design engineering as small teams can now do more with less. A single interdisciplinary builder can cover ground that once required an entire cross-functional team. They bring together creativity, engineering, and strong design judgment in their problem-solving. This maps closely to what Marc Andreessen describes as the “E-shaped” career. Rather than having a single deep spike in one area of expertise, design engineers develop multiple prongs of depth across the product spectrum, leveraging AI and their collaborators as force multipliers that extend each prong further. With all of this, design engineers can build experiences at the speed of sheer imagination.
Design engineers = fluidity across the stack
Design engineers are fluid by nature. They have spikes in one or two areas, but flex depending on the problem they’re solving.
Someone might be deeply customer-obsessed and exceptional at rapidly validating new product ideas, while relying on design partners for visual direction, engineering peers for production implementation, and leveraging agents to fill in gaps. Some work might require deep knowledge of both visual and technical expertise, e.g., specializing in delightful + performant motion, animation, and micro-interactions.
As products evolve, so do the people building them. A prototype hacked by a design engineer that’s now becoming a production feature creates an opportunity for its creator to lean more heavily into software engineering to see it through. Likewise, a product engineer might be more fascinated by interaction design and motion and gradually develop a stronger visual practice over time.
It’s worth thinking about slope vs. y-intercept. A design engineer’s value compounds as they develop context about your product, users, and team. Hiring one is almost like a VC betting on a founder: you’re betting on trajectory and influence, not just current skill. The best design engineers are deeply curious, adaptable, learn quickly, and take great pride in their craft. They tend to have T-shaped skills with expertise in one area and the ability to stretch across many others, which makes them especially adaptable as business needs shift. Many design engineers are excited about working at places that let them flex across the stack.
Understanding the design landscape
Design engineers come from a range of backgrounds, from product designers who’ve picked up coding, engineers who deeply empathize with design, and everything in between. Those backgrounds and interests shape the kinds of work they gravitate toward and where they contribute most.
To understand where design engineering fits, it helps to look at the broader design landscape within a company, from brand and visual expression to interactions, prototypes, design systems, and production components. Below, I’ve illustrated this range of work alongside three common archetypes. These aren’t fixed “zones” or an exhaustive list: people can have spikes in multiple areas across the spectrum, and new tools continue to open up new ways of working in design.
Visual storytellers/creative technologists
These designers use code as a medium of expression. They use it to create emotion, communicate ideas, and shape how people experience a product. Their work spans landing pages, launch experiences, marketing sites, and brand, often setting the visual bar and product narrative for the rest of the team. Creative technologists may also combine code with video, 3D, sound, or physical installations, exploring new forms of interaction through experimental products and special projects.
This archetype is becoming increasingly valuable. AI companies are investing heavily in creators to make their technology resonate with everyday consumers, and we’re seeing new in-house creative roles emerge at frontier labs to bridge this gap. Creative technologists have the unique ability to build things and tell stories that resonate while making complex technology feel more tangible.
Product Designers who tinker
On the more exploratory side, we have designers who tinker, using code to think through complex product problems. Rather than treating code as their final artifact, they use it to explore ideas, prototype interactions, and develop intuition for how new product paradigms should work. This lets them explore ideas with real data, test new interaction patterns, and validate concepts against real product constraints in ways static design tools can’t.
As you move from exploration to implementation, you have more systems-oriented designers. They think about designing for scale, codifying components into design systems, and developing models and primitives across the application, and they primarily serve other developers.
Others can be more deeply user-oriented - rapidly prototyping concepts to uncover user needs almost as a “forward-deployed designer” and shape product direction.
S/O to Flo for helping create this definition :)
Engineers with strong design sense
People in this archetype are more technical/engineer-first, with code as the final artifact. They care deeply about turning ideas into robust, scalable software while maintaining a high bar for user experience.
Some are product-focused engineers who comfortably move between product strategy, design, and implementation to ship features end-to-end. Others specialize in frontend engineering, building robust component systems, polished interactions, and performant user interfaces while maintaining high standards for code quality and maintainability.
How stage and company shape the role
Defining the archetypes is only one half of the picture - the needs also heavily depend on the stage of the company and the skills of the existing members of the team.
At larger companies, there’s more room for design engineers to hyperspecialize: focusing on high-craft components and interactions, or functioning as an innovation/enablement team that incubates new ideas and builds tooling to accelerate product development across the org. The highest-leverage design engineers at this stage are great at rallying people together and unifying visions across research, design, and product to make stuff happen.
At early-stage startups, most design engineers lean more technical, where writing production code is a baseline expectation, but it really depends on the shape of the rest of the team. If a founding design engineer is one of the only engineers working on user-facing code, they’re typically expected to be more senior on both the design and technical front. If there are no other designers on the team, they’ll need to set visual direction, make product decisions, and may end up spanning product design, prototyping, design systems, and even marketing assets.
Company platform and domain also play a large role here in how technical you need your designers to be. If you’re building a developer tool, it’s natural to prefer designers with a bit more of an engineering background, so they’re immersed and opinionated on the product they’re designing for. If a company’s product is mainly web-based, the barrier to entry is much lower for anyone to contribute to production code by leveraging agents. Platforms for TV and mobile add much more complexity to development setup and deployment pipelines. Designers can learn these platform-specific nuances, but the question is whether it’s worth the effort. Many design teams are now building internal tools or looking into external solutions (ex. Magic Path, Dessn, and others) to enable more designers to prototype in production.
The reality is many early-stage companies are drawn to the title because they want prolific, interdisciplinary builders who can wear many hats but haven’t thought deeply about what the role looks like in practice. It’s worth asking yourself: why are you hiring a design engineer specifically vs. a front-end engineer or a product designer, and how technical do you need them to be?
In my opinion, design engineers do their best work when they have specialists to lean on: strong researchers, backend engineers, dedicated designers. That support structure lets them focus on the intersection, which is where their unique value lives. Some design friends have jokingly said that designers are like penguins; they work best in groups where they people to riff with on their ideas.
Should all designers push code to production? The question to ask instead is: where does this person create the most leverage? A designer who thrives in exploration may be slowed down by spending days polishing production PRs. The best teams understand these differences and create environments where people can spend more time working in the medium that’s most natural to them, while still giving them room to grow into new ones.
Is design engineer the final form?
New roles emerge to make changing ways of working legible. But not all of them stick. Prompt engineering is a good example: it exploded as a distinct role in 2023, then gradually became a capability expected across existing roles as the technology and skills matured.
We’re now seeing a similar proliferation of titles with “engineer” appended: talent engineer, GTM engineer, content engineer, and so on. Some of these roles overlap with engineering roles, where they build tools, systems, and automations in a particular domain. Others borrow the problem-solving and agency associated with engineering without necessarily involving traditional engineering work.
Part of the appeal is that the word “engineer” carries weight. Engineering is traditionally associated with rigor, technical depth, applied science, and mathematics. Adding it to a title signals agency and an emphasis on building, which makes the role more attractive to people who may not have considered it otherwise. It can also make the technical aspects of the work more legible to others.
I’ve seen this play out firsthand. My role was originally called “Design Technologist” before we changed the title to “Design Engineer” to follow suit with what’s happening in industry. My background was previously in product engineering roles, and I studied engineering in school. Although most of the actual work was writing React/JavaScript code, the role “Design Technologist” didn’t read as very technical to my peers. The moment we shifted our titles to Design Engineering, the legibility completely shifted.
But that legibility comes with baggage. As Flo Guo recently shared, she’s gone back to introducing herself as a designer rather than a design engineer. At a design engineering meetup I attended, many people expressed a similar sentiment, particularly those who came from product design and later adopted coding as a skill. Adding “engineer” to the title can create expectations around production PRs, test coverage, systems design, and software engineering rigor. For someone who sees code primarily as another medium for expressing and prototyping ideas, and who entered the design engineering world through that lens, those expectations create tension in how they identify themselves.
Interestingly, some companies have moved in the opposite direction entirely. AI labs have titles like “Member of Technical Staff,” “Member of Design Staff,” and “Member of Non-Technical Staff,” with variations that keep the organizational bucket broad while leaving the actual work relatively undefined. A growing number of AI startups are adopting similar language, inspired by the title’s roots at Bell Labs. This gives people more flexibility to take on whatever work falls under the broader team, based on the project’s needs, rather than boxing themselves into a role.
It’s hard to know exactly where design engineering will go. I hypothesize that the role eventually converges into a broader product maker: someone who can move fluidly between understanding the customer, shaping the product, designing the experience, and building it. Rather than hiring specifically for “design engineering,” companies might instead hire for this broader ability to make things happen end to end, and evaluate candidates based on where their particular spikes lie, whether that’s product design, strategy, growth, product engineering, systems, or backend. In that world, the question isn’t: “are you a design engineer”, but “what kind of maker are you?”
Parting thoughts
Thank you so much for reading! Design engineering is still taking shape, and there may never be one “right” definition of the role. I hope this helps those curious about design engineering gain a clearer understanding of the field and spark some interesting discussions of where the industry is heading. I’d love to hear more takes; feel free to reach out on Twitter, or join us at designeng.club to hang with others working across design and engineering!
What excites me most about this moment is how much further we can take an idea with the tools we have! As code becomes more accessible as a creative tool, the boundaries between designing an experience and building it are becoming more fluid. I’m really curious to see what cool things people will create and how these new ways of working will evolve roles and the teams around them.
I wanted to share other pieces of work that some awesome people have written about the design engineering discipline already: David Hoang wrote about the Design Engineering role in 2024, Marcelo Chaman from Gumloop published an essay about design engineering in the early start-up environment recently, Filip Wojda wrote about design engineers being an artist at heart and Vercel also has a guide about how they define design engineering at the company. I also really enjoyed Jenny Wen’s podcast with Lenny on the evolution of design. Please send other reads my way!
Stay tuned for part 2, where I’ll be writing about how to attract design engineering talent, and part 3 on how to evaluate them.
Special thanks to these incredible individuals for their thoughts and feedback shaping this piece:
Flora, Sabina, Tina, Arjun, David, Mackenzie, Vardnan, Filip, Sourabh, Leona, Jane, Matt, Chloe, John, Marcelo, and Hanhbee.
Very insightful, Mathu. Excited for further parts to come of this series.