A role between two rooms
Nobody agrees on what to call the job. Maggie Appleton, collecting examples of it in A Collection of Design Engineers, calls “design engineer” the latest label thrown onto a pile that already holds interface designer, interaction designer, UX engineer, and front-of-the-front-end engineer. She keeps the new label anyway, because it captures something worth distinguishing: “a person who sits squarely at the intersection of design and engineering, and works to bridge the gap between them.” Such a person can run a design process to decide how something should work, look, and feel, and has the engineering skill to ship it, iterating by cycling between design exploration, research, and live code.
The companies that employ design engineers describe the role by its output. Vercel’s design engineering team, in Design Engineering at Vercel, says its members “blend aesthetic sensibility with technical skills,” which lets them understand a problem, then design, build, and ship a solution autonomously. The list of what they care about is not a list of pixels: delightful interactions and affordances, reusable primitives, page speed, cross-browser support, touch and pointer input, user preferences, assistive technology. “There is a lot of work behind the pretty pixels,” the post says, and most of this book is about that work. Designers at Vercel sketch a start and iterate with a design engineer in Figma or code; there is no handoff, and animation, keyboard control, and touch are prototyped directly in the browser because rebuilding them from another medium wastes the effort.
Kathryn Gonzalez built the practice at DoorDash, starting as its first product designer and ending up leading design infrastructure. Her The Attributes of a Design Engineer refuses the easy version of the job (“a designer who knows how to sling some React”) and names three attributes instead: building with significant autonomy, practising and teaching great software craft, and elevating the final fidelity of what gets made, from start to end. Her summary is that a design engineer “loves the craft and the materiality of building software,” and that what they bring to a company is the ability to elevate what everyone else builds. The lineage, she notes, is long: creative technologists, Flash developers, design technologists, UX engineers. The name changes; the mindset does not.
Jim Nielsen makes the economic argument. In The Case for Design Engineers he counts the artifacts a responsive design produces when designers and developers work in sequence (sketches, wireframes, mockups, prototypes, each at several sizes, up to sixty per iteration) and observes that a design engineer collapses the pile. They understand the constraints of the medium, so they produce one or two artifacts while keeping in their head how the elements flex and flow across sizes. “There’s no need to explicitly design and document all possible states for whoever is downstream of the designs because they are the ones downstream of the designs.”
Read together, the four definitions agree on more than they differ. The role is defined by ownership of an outcome rather than a slice of a process, by fluency in the material (HTML, CSS, the browser, the device) rather than in a tool, and by caring about details that most people will never consciously notice. The book that follows is organised around those details in five parts. Feel covers how interactions respond (Invisible details) and how motion is used and withheld (Motion). Build covers how small components are built well (Components) and how the web is treated as a material (Craft). Judge is about how taste is trained (Taste). Explain covers interfaces that teach (Explaining with interaction) and canvases and tools for thought (Canvases). Work is what the career looks like from inside (The career).