# The case for design engineers · The career Jim Nielsen has blogged for fifteen years and says “Design Engineer” is the job-title bucket closest to his sense of self, “that or just plain old ‘Web Designer’.” His three-part case is the most quoted argument for the role, and it is about process, not skills. ### Too many artifacts [The Case for Design Engineers](https://blog.jim-nielsen.com/2022/the-case-for-design-engineers/) (26 May 2022) reacts to Jason Grigsby’s “Traditional Web Design Process is Fundamentally Broken.” For responsive design “there are Too. Many. Artifacts.”: sketches, wireframes, mockups, prototypes, each in at least three sizes, up to sixty per iteration by Grigsby’s count, with iOS alone at thirteen breakpoints, and none capture how the design behaves in the browser. That “helps show why design engineers are worth their weight in gold.” They know the medium, so they make one or two artifacts and hold the rest in their head, and they need not document every state “because they are the ones downstream of the designs.” He calls this **declarative design** (Jim Nielsen's contrast: declarative feature design is a couple of mocks, a few rules, and a design engineer; imperative feature design is innumerable mocks and rules with a strict waterfall between designers and developers.): a couple of mocks, a few rules, and a design engineer, versus a strict waterfall. “At what quantity does a set of declarative rules begin to look like imperative instructions?” ### Feel cannot be specced [Pt. II](https://blog.jim-nielsen.com/2024/the-case-for-design-engineers-pt-ii/) (12 February 2024) is about feel. You get a note: the line between two containers should be draggable. “Perhaps that note is all you get.” Open questions: is there a resize affordance, on mouse in or mouse down, immediately or delayed, on the line or in a target area and how big, with snapping? His own build “felt off” until he saw the trigger area was asymmetrical between the two boundaries. “Sometimes you just have to feel it, use it, to understand the nuances.” So “you need someone who can do design work with code.” Pixels from a GUI tool are “a static representations of a dynamic form,” a picture of him versus the moving him; designing in code makes the artifact the deliverable in embryo, and review becomes sending links. He allows two people, if they are close enough that the thing “feels designed all the way through.” [Pt. III](https://blog.jim-nielsen.com/2024/the-case-for-design-engineers-pt-iii/) (27 March 2024) borrows Christopher Nolan’s Writer/Director credit: films, like websites, are drafted outside their final medium, so meanings are found in production. “The creative process is not an assembly line,” and with narrow roles, “if what was planned on paper doesn’t work in reality, you’re stuck.” [Making Films and Making Websites](https://blog.jim-nielsen.com/2024/making-films-and-making-websites/) states **the only source of truth** (Jim Nielsen's rule that the only source of truth is the website people access and use; design system components, Figma mocks, and research data are tools in service of that final form.): the website people use. “People come to watch films, not read scripts. People come to use websites, not look at mocks.” [The Figma to Browser Chasm](https://blog.jim-nielsen.com/2023/figma-to-browser-chasm/) (2023) is the business version: a Figma file that never reaches the browser means “you’re throwing away time and money,” unless “you’ve got a design engineer who can do both.” Source Dates from the posts and Jim’s #designEngineer tag: Pt. I 2022-05-26, Pt. II 2024-02-12, Pt. III 2024-03-27, Making Films and Making Websites 2024-03-19. ### The same case, run for years Kathryn Gonzalez’s systems writing is the role inside a company. [Design Systems and Infrastructure](https://www.ryngonzalez.com/blog/design-systems-and-infrastructure) (July 2018) lists a Design Language System for web, Android, and iOS sharing type, colour, and spacing through tokens, and components that made “the hard, tedious, error-prone work of building things like modals” no effort. Design had two halves: generative exploration, then **productionizing** (Kathryn Gonzalez's term for taking explorations and making them work in the context of the design and engineering systems, accounting for edge cases and existing patterns.), making micro-interactions “repeatable and low-cost” by engineering them once. [How to Build a Modal](https://www.ryngonzalez.com/blog/how-to-build-a-modal) (2017) is the ground truth: a z-index problem (a LayerManager with its own stacking context), focus management (the WAI-ARIA examples “are your friend”), an iOS scroll lock overflow: hidden could not provide, and “Always test with real devices.” The system “is made of processes as much as components,” and her [Config 2023](https://www.ryngonzalez.com/blog/design-systems-in-transition-anxiety-ai-and-where-we-go) line, that the extra ten percent of polish makes “your designers truly trust your system,” is Jim’s argument at organisational scale: built once by someone who could do both, handed to everyone. ### How the role is received In [Interdisciplinary Website Maker](https://blog.jim-nielsen.com/2024/interdisciplinary-website-maker/) (April 2024) interviewers “look at me strange and stammer”: “Why would we need a designer that codes? We have designers. We have coders.” Now “any cross-disciplinary interest is easily interpreted as a lack of specialization.” He borrows Paul Ford’s “the interdisciplinarian is essentially an exile” and floats “Interdisciplinary Website Maker,” as Maggie Appleton calls herself a website maker. An earlier post on the [tension between logic and creativity](https://blog.jim-nielsen.com/2023/logic-of-code-and-illogic-of-creativity/) says design engineers “have developed a muscle for holding these tensions in balance.” The coda is sober. In [The Tumultuous Evolution of the Design Profession](https://blog.jim-nielsen.com/2025/tumult-in-design/) (May 2025) he accepts that “bad design doesn’t hurt profit margins,” or nothing proves it does, while cost savings always show; he quotes Elizabeth Goodspeed’s “Less craft, more optics” and adds that optics are often better for your career than building. Kathryn’s “precarious” footnote says the same from the other side. The case is strong; organisations do not automatically make it. When you must, use Jim’s three moves: count the artifacts one responsive feature produces, build the interaction that has a note instead of a spec and send the link, and when a plan fails in the browser, say so and change it.