Your own site as proof
Maggie Appleton’s method for understanding the role was to “find and follow people doing design engineering work in public, and pay attention to their outputs, skills, and responsibilities,” and her collection lists only people who publish. For a design engineer, the public work has a natural home. A personal website is an interface you designed, built, and shipped alone, with nobody downstream of you; by Jim Nielsen’s rule that the only source of truth is the website people use, it is the one place where your taste (what you chose to make) and your craft (how it is built, down to the unit you set the font size in) are on the record at once. This section reads several of them.
Andrew Swank’s site is the most literal. He describes himself as “a designer and engineer by design,” and a section titled “This site” begins: “I invite you to play with this site. I’ve built this from scratch and welcome feedback. The goal is to show how design and engineering can work together to create a better experience for both parties.” The features he lists are the decisions: layout and typography sized with vmin and rem units to set the baseline font size; predictable sizing via max() and round() to snap to a 4-pixel grid; HSL custom properties so colours can animate without dulling (“hover over the logo”); a variable font, Roboto Flex, animated smoothly with font-variation-settings. The project pages do the same with his Google work. For Assistant, as a UX Engineer, he built a toolkit that let designers prototype voice interactions without code, “reaching 400+ cross-functional users and powering 8000+ voice prototypes,” with a Chrome extension that put voice into Google Slides, a speech service handling recognition and synthesis, and a React component library for Assistant’s visual elements. For Google Flights he created the mobile datepicker that was “later selected as the Google standard, used by billions,” adopted as the Material Design standard and then by the MUI React library; his reference implementations, he reports, cut engineering implementation time by more than half. The datepicker page does not show screenshots of this. It runs a recreation he calls “fairly faithful” and states its rules: you can start with a departure or a return date, the other end can then be any date, and if you pick a return before the departure “the system automatically swaps them to create a valid range.” Before you pick, each day shows the cheapest round trip starting that day; after, the total for that trip. The site demonstrates the component instead of describing it.
Kathryn Gonzalez’s Personal Website, Personal Shrine (July 2023) is about what a site is for. She has rebuilt hers “a half-dozen or so times over the last 15 years,” and likes that each version is “a reflection set in a particular time of where I am as a designer, as an engineer,” and, primarily, as a person. For almost eight years she barely changed it while her name, her career, and her company changed, and the post is the correction: three principles, share openly and consistently, reflect back the fullness of who she is, and play, experiment, and foster a creative hunger. The build follows the first principle. She wanted the authoring tool to be “easy for me to pickup” and as frictionless as she could make it, so the site reads from Notion through react-notion-x and is pre-rendered with Next.js static generation so that reading it is fast; a /bits page holds the small things she learns in a week; the home page stickers are built with Framer Motion “to introduce fun, physical moments.” She closes with Clay Shirky on Shinto shrines, rebuilt continually and lasting because of the rebuilding, and wants a site whose solidity comes from the act of learning, sharing, and making rather than from what it is at any one moment; hence the title. Her inspiration list is itself a reading of other people’s sites: Lee Byron’s understated pages with scroll-driven animation, by someone she wants to emulate for having “somehow straddled design and engineering”; Petter Nilsson’s “Two colors, left-aligned, one font-size. It’s an exercise in restraint that I respect and admire.”
Restraint is also where Paco Coursey landed. Redesign 2021 explains why he stripped paco.me down to documents and links. The year had left him scattered, and the cleanup was a conscious effort to refocus: “Instead of adding as many animations, features, and case studies as possible, this iteration reflects my values of performance, simplicity, and craft.” He wanted the site only to describe him, what he is thinking about, and what he is building, and admits how hard that was, because “it feels like everything I build must use some novel interaction”: what if each page were a frame on an infinite canvas, or the site were a little OS, or each page had changing weather? Landing on documents and links felt like a step backward, but his previous site “felt disingenuous and abandoned,” and in this one there is practically nothing to keep up to date. He also resolved the tension between building for others and for himself: “If you leave your home unlocked, it is no longer a home, but an exhibition.” The colophon is the craft: set in Inter, Söhne, and Newsreader “with a particular focus on typography that feels good,” built with Next.js with JavaScript disabled, because you do not need it to read documents. The interaction work lives one page over, on a craft page titled “Implementing interfaces and interactions”: exclusion tabs after Stripe’s, an iOS 16 dropdown whose nested items expand in place behind a clip-path, three approaches to blur, a re-implementation of Linear’s timeline with native scrolling.
Rauno Freiberg’s craft page is that idea turned into a log. It lists 78 entries from 2021 to 2026, nearly all dated, each labelled Read Essay, View Prototype, or View Production, or left as a video tile. Six are essays; the prototypes run from Vanish Input and Radial Menu to a Minimap and a Logo Carousel; the production entries include the Vercel design page, his running diary, Devouring Details and its system, and History of Software Design. Nothing on the page is a case study. It is dated evidence, and the home page footer states the standard it is held to: “Make it fast. Make it beautiful. Make it consistent. Make it carefully. Make it timeless. Make it soulful. Make it.” Maggie Appleton’s site is a garden, “a collection of imperfect notes, essays, and ideas growing slowly over time,” which she designed and built herself and publishes as open source: Astro, MDX, Canela for headers and body, a fluid type scale from Utopia, animations mostly in CSS, and a growth stage on every post (seedling, budding, evergreen) with the dates it was planted and last tended. Her design engineers note is marked budding; the discovery of the role happens in the open. Jim Nielsen’s about page gives the numbers behind fifteen years of writing, 805 posts and 580k words, and his home page is a list of verbs: I’m Blogging, I’m Link Blogging, I’m Collecting iOS Icons, I’m Baking Pies. Emil Kowalski’s home page is a few sentences (the Web team at Linear, previously the design team at Vercel), four projects with one line each (animations.dev, Sonner, aiforui.dev, Vaul), and a writing list with one-line blurbs. Each of these reads as a portfolio without containing one.
What a blog post reveals is the subject of the shortest post in this chapter. Jim’s Job Screening Blog Post (November 2024) is two animated GIFs of a button being clicked and the UI changing. In the first the heading shifts upward by one pixel; in the second it does not move. The whole text: “Can you tell the difference between them? Do you care? If not, we might not be a good fit.” That is the screen, and it runs in both directions. A post like Sanding UI, where he finds the dead click zone that a flexbox gap left between a radio and its label and fixes it with padding on the label, shows a reader what he notices and what he does about it better than a line on a résumé could. Kathryn says the same of her 2015 piece on designing search for DoorDash: “This is the article that got me the most important job of my life (so far).” Maggie’s caveat still applies, the shiny work is over-represented online, but the fix is in your hands: write up the splinter, not just the finish.
If you build one thing after this chapter, build your own site, and build it yourself rather than from a template, because the choices are the point: the type, the grid, the unit the font size is set in, whether JavaScript is needed at all. Make one page where a component runs instead of being described. Keep a dated log of prototypes. Write down the one-pixel decisions. The site is where a design engineer’s taste and craft are both visible, and unlike the work you did inside a company, nobody has to take your word for it.