The attributes of a design engineer

Kathryn Gonzalez joined DoorDash in 2015 as its first full-time product designer and frontend engineer, after dropping out of college for the second time, when the company was, in her words, “only a handful of us working out of an old Animal Hospital in Palo Alto.” She spent two years as a lead product designer across Consumer and Merchant products, started DoorDash Drive, led frontend engineering across audiences, and then spent six years building and leading the Design Infrastructure org (design systems, design engineering, prototyping, accessibility), starting as an individual contributor and ending as a manager of managers over an org of twenty-five people. She left in January 2023, after almost eight years, and a little over a year later published The Attributes of a Design Engineer, which her blog index describes as “My definition of design engineering after building the practice at DoorDash.” A photo in the post marks the moment she officially became a design engineer (aka design technologist) there in 2017, “CEO approved!”

The post opens by noticing that “Design Engineering seems to be having a moment”: Vercel had just published its own account of the role, David Hoang had written about why it would matter in the coming decade, and the timeline was full of threads. Kathryn’s first move is to deflate the novelty. The role has existed in many forms over many years, she writes, listing creative technologists, Flash developers, design technologists, and UX engineers; each iteration changed the tools and the scope while the core stayed the same. Her second move is to refuse to define the role by its tools. Most people, she observes, narrow it in exactly that way: “are they a designer who knows how to sling some React? Or are they an engineer that has an eye for design and is comfortable in Figma?” After a decade in the role she would rather define it by outcomes, and the sentence she lands on is the spine of this chapter. Design engineering is living at the intersection of those practices, and using a broad understanding of both sides to build with significant autonomy, practice and teach great software craft, and elevate the final fidelity of what’s made from start to end. Those three attributes can show up in different jobs: roles focused on design systems and infrastructure, roles focused on prototyping new ideas, and roles focused on shipping products with craft at their core. She has held all three.

The autonomy attribute is told as an origin story, and she is honest about it. She likes to say that design engineering at DoorDash began as a deliberate recognition that design and engineering needed to live together in one role. “In truth, it started because they hired me as their first product designer, and quickly, I made it known that I didn’t see the scope of my role being just a person who lived in Sketch (pre-Figma).” Designing, to her, was one step in making software; getting the design real was part of the same job, and her responsibility was “the full ownership of what we shipped,” the outcome rather than the deliverable. The company at that point had no full-time product designers and no full-time frontend engineers: a brand designer, an intern, a technical co-founder filling gaps from the design side, and a group of backend-leaning full-stack engineers building the frontend. So she filled both gaps, defining and then building the internal menu editor, the web version of the consumer site, and the first Merchant tools, end to end. The DoorDash.com of 2017, she notes under a screenshot, was designed and built by her. Her conclusion generalises past her own story: startups are highly motivated to hire people who can act as an owner, end to end, of what they produce, and design engineers are what that mindset looks like as a practice.

The second attribute is about material. “Great design engineers are obsessed with understanding the materials of software, all the specific affordances of the medium, and the tools you use to shape them.” The obsession, in her account, comes from wanting to make something with both beauty and intentionality while also wanting to be technically independent enough to build it. She calls the resulting people “software makers,” strong at both the technical and the creative, and the tell is what they choose to learn: tools others find too intimidating technically (shaders, 3D materials, physics-based animations) or too wasteful for anyone focused on getting anything that worked out the door “but not the right thing executed exceptionally well.” Her own examples are concrete. She relished the projects a non-technical designer could not do at the time, prototyping micro-interactions and animations in Principle, Framer, and straight code. And in 2015, when React was young and DoorDash’s engineers were maintaining Backbone, vanilla JS, and Angular 1 of varying quality, she migrated the frontend to React and built the infrastructure that let the team ship UI with more safety and speed. The teaching half followed from that. She had learned at Fetchnotes how hard it is to make a web-stack mobile app feel fluid and high-craft, so she shared that with the full-stack engineers and helped hire frontend engineers with the same attention to detail.

The third attribute explains where the role tends to live. “One of the unique aspects of design engineering is that you’ve got the potential to have much of the full process of building software contained in one person.” That lets you try ideas yourself, build more faithful renderings of other people’s ideas, and give the work deeper attention than a chain of handoffs allows. Her favourite DoorDash projects were explorations of new product areas that could not be expressed as static designs, and they taught her a line worth keeping: “Selling a vision to customers, or other people in your company, sometimes requires a magic trick,” something that feels pulled from the future even if under the hood it is not quite real. But the same translation skill also makes design engineers good at building infrastructure that raises the fidelity of everyone else’s work: design systems, tools, shared language. That, she argues, is why design engineers are most frequently found at large companies on design infrastructure and systems teams; they elevate the practice across a large scope even when the team itself is small. At DoorDash that was where she found the most value as the company grew, and “we were a leading system by the time I left.”

What she looked for when hiring is on record from the middle of that period. In a 2020 design leadership interview she described the team’s job as enabling partners in design, product, and engineering “to build better products faster, and to make better product decisions more efficiently,” and the people she wanted as “really strong at bridging the gap between design and engineering”: super detail oriented, curious about the similarities and differences between the disciplines, and able to make other designers and engineers better. The open role at the time was a Design Technologist for iOS who had to know the pain points of building UI with UIKit, and who also had to “love and appreciate the craftsmanship in building UIs.” “It takes a very particular kind of person to be comfortable sitting at that intersection,” she said, and she wanted to make space for them. Her 2018 post Design Systems and Infrastructure, written when the team was officially just her, had already framed the goal as “a home where people who love both design and engineering can use their skills,” because she had always been a hybrid and had always struggled with having to pick a side. She defines design infrastructure there as sitting at that intersection and supporting both sides “through our tools, systems, communication and most importantly, our shared empathy of design and engineering.”

The post ends with the negative definition and then the positive one. “Design engineering is not just a designer who codes or an engineer who has an eye for design and the courage to edit a Figma file.” A design engineer sits at the intersection of both practices, loves the craft and the materiality of building software, needs a mindset of autonomy and an excitement about being an end-to-end software maker, and brings an organisation the ability to elevate what everyone builds: “better software, more truthfully expressed.” She expects the role to become more common as AI makes each side of the divide easier to participate in, and two footnotes hint at the posts she planned next: design engineers make great founders because they can carry a clear vision to a well-executed outcome, and being a design engineer as a career “can be precarious.” In a travel essay written during her break, she wondered whether she could “again be the one that coded and designed the thing rather than the one that supported the person who made the thing.” The pull toward the intersection did not leave with the title.

For your own work, the useful part of Kathryn’s framing is that none of the three attributes is a tool. You can start practising each of them in whatever role you hold now: take ownership of an outcome rather than a deliverable, learn the material well enough to teach it to the person next to you, and look for the one place where a higher-fidelity version of something would change a decision. In her telling, the title came two years after the behaviour.