The case for design engineers

Jim Nielsen has been blogging for fifteen years and says that if he had to pick a job-title bucket, “Design Engineer” would be closest to his own sense of self-identification, “that or just plain old ‘Web Designer’.” His three-part case is the most quoted argument for the role, and it is an argument about process rather than skills. The Case for Design Engineers (26 May 2022) reacts to Jason Grigsby’s “Traditional Web Design Process is Fundamentally Broken.” For responsive design, Jim writes, “there are Too. Many. Artifacts.”: sketches, wireframes, mockups, prototypes, each in at least three sizes, up to sixty artifacts per design iteration by Grigsby’s count, and current iOS devices alone accounted for thirteen breakpoints. Grigsby’s verdict, which Jim quotes, is a waterfall producing dozens of artifacts none of which capture how the design will look and behave in the browser. Jim’s response is that the artifact explosion “helps show why design engineers are worth their weight in gold.” They understand the constraints of the medium, so they produce one or two artifacts while holding in their head how the elements flex and flow across sizes, and they do not need to document every state for whoever is downstream, “because they are the ones downstream of the designs.” He connects this to declarative design: a couple of mocks, a few rules, and a design engineer, versus innumerable mocks and rules and a strict waterfall between designers and developers. “At what quantity does a set of declarative rules begin to look like imperative instructions?”

Pt. II (12 February 2024) moves from artifacts to feel. You are handed a design with a note: the dividing line between two containers should be draggable so the user can resize them. “Perhaps that note is all you get.” Either way it is not everything, and he lists what it leaves open. Does the interaction have a resize affordance? Does it appear on mouse in or mouse down? Immediately or on a delay? Directly on the line or in a target area, and how big is the target? Is there snapping? He had just built such a feature, and it “felt off” until he realised the area that triggered the affordance was asymmetrical between the two boundaries. “It’s hard to even articulate this scenario with words and pictures. Sometimes you just have to feel it, use it, to understand the nuances.” From that he draws the claim the whole series rests on: look and feel is hard to design, let alone spec, in a design tool, so “you need someone who can do design work with code,” someone who understands the medium you will deliver in rather than the one you design in. Pixels from a GUI tool are “a static representations of a dynamic form,” the difference between a picture of him and the living, breathing, moving him. Designing with code does not produce an approximation that then needs translating; the artifact is the deliverable, in embryonic form, and the design review becomes building something, sending people links, and asking what they think. He is careful to allow the two-person version: either one person who works in both forms, or two who work closely enough to nail down every detail until the thing “feels designed all the way through,” not designed and then implemented.

Pt. III (27 March 2024) borrows Christopher Nolan’s “Writer/Director” credit. Nolan describes sitting at his laptop, writing a scene, and handing it to Gary Oldman; in a world where people can only be writers or directors that would be an unusual and unnatural state of affairs. Making a film, like making a website, is iterative, and its drafts are not even in the medium of the final form (screenplays, static mocks), so many meanings can only be discovered in production. “The creative process is not an assembly line,” and the risk of narrowly defined roles is that “if what was planned on paper doesn’t work in reality, you’re stuck.” A week earlier, in Making Films and Making Websites, he had put the principle in one line: in making websites, the only source of truth is the website people access and use, and everything else, from design system components to Figma mocks, is a tool in service of the final form. “People come to watch films, not read scripts. People come to use websites, not look at mocks.” The Figma to Browser Chasm (2023) makes the business version: if you cannot translate the hours and talent sunk into a Figma file into working code in the browser, “you’re throwing away time and money,” and you capture a talented designer’s full value only with an equally talented engineer, “or, if you’re lucky, you’ve got a design engineer who can do both.”

Jim’s argument is about one feature at a time. Kathryn Gonzalez’s design systems writing shows what the same role produces when it runs for years inside a company. In Design Systems and Infrastructure (July 2018), when the team was still officially just her, she could already list a Design Language System shipped for web, Android, and iOS; libraries sharing typography, colour, and spacing across platforms through design tokens; a component system that made “the hard, tedious, error-prone work of building things like modals” no effort for design or engineering; and a start on shaping how designers and engineers communicate. Her framing of design at DoorDash has two halves, both needed: being generative and exploratory to find the right shape of a solution, and then productionizing those designs, accounting for edge cases and existing patterns and working alongside engineering to make them truly work. The aim was to make complex micro-interactions “repeatable and low-cost” by engineering them once and reusing them, so product designers and engineers could spend their attention on product problems. How to Build a Modal (2017) is the ground-level evidence: a modal that seemed simple turned up a z-index problem (solved with a LayerManager that renders modal content into its own stacking context), focus management (the WAI-ARIA examples “are your friend”), and an iOS scroll lock that overflow: hidden could not provide, plus the confession that they had tested only in Chrome’s responsive mode and the lesson “Always test with real devices.” Her takeaway there, that the system “is made of processes as much as components,” and her Config 2023 line that the magic of a system is the extra ten percent of polish “that make your designers truly trust your system,” are the organisational form of Jim’s design-in-the-browser: the interaction designed and built once, by someone who could do both, then handed to everyone.

Jim is also frank about how the role is received. In Interdisciplinary Website Maker (April 2024) he describes interviews where expressing a desire to do design and code makes people “look at me strange and stammer,” the sentiment being “Why would we need a designer that codes? We have designers. We have coders.” In the early web “a designer who codes” was ordinary, since the only place to procure people who made websites was Craigslist; now “any cross-disciplinary interest is easily interpreted as a lack of specialization and dedication to craft.” He borrows Paul Ford’s line that “the interdisciplinarian is essentially an exile” and Ford’s tree, which no single discipline explains, then admits his own degree is a Bachelor of Science in Interdisciplinary Studies with an emphasis in Visual Technologies and Spanish, “more Graphic Design than anything programming-related.” Design Engineer fits him because it is deliberately cross-discipline and satisfies “don’t put me in a box,” but even it “leaves out all the others,” which is why he floats, half-joking, “Interdisciplinary Website Maker,” and points at Maggie Appleton calling herself a website maker for the same reason. An earlier post on the tension between logical reasoning and illogical creativity says why he values the combination: design engineers “have developed a muscle for holding these tensions in balance,” the logic code demands at every step against the subversive ideation that reaches unseen but plausible possibilities.

There is a sober coda. In The Tumultuous Evolution of the Design Profession (May 2025), reading Elizabeth Goodspeed on designers’ disillusionment, Jim accepts the hard truth that “bad design doesn’t hurt profit margins,” or at least that nothing obvious proves it does, so most decision makers do not care, while cost savings always show up. He quotes Goodspeed’s “Less craft, more optics; less idealism, more cynicism” and adds a line about himself: being good at building is great, but being good at the optics of building is often better for you, your career, and your standing in many organisations. Kathryn’s footnote promising a post on “why being a design engineer as a career can be precarious” points at the same thing from the other side of the org chart. The case for design engineers is strong. It is not automatically the case that organisations will make.

When you need to make the case yourself, use Jim’s three moves in order. Count the artifacts your current process produces for one responsive feature. Pick one interaction that has a note instead of a spec (a drag handle, a hover delay, a snap) and build it rather than describing it, then send the link. And when a plan does not survive contact with the browser, say so and change it, because that is the work, not a failure of the plan. Kathryn’s posts are what the same habit looks like once it is shared: the modal built once, the tokens shared across three platforms.