Coding is designing

In June 2026 Jim Nielsen published a post short enough to quote almost whole. It is called Coding Is Designing, and its first line is the argument: “Code isn’t just a way to implement a design, it’s a way to find one.” An interface, he writes, is something you have to use, feel, interact with, and poke at before you can see the relationships between its parts. Change one thing and watch another react. If it does not feel right, tweak it. Change the first thing again, and now the second reacts differently. You keep going until the disparate elements settle into a single whole. His closing line gives the chapter its frame: “Design is ‘how it works’ and code is the tool to specify how it works.”

That sounds obvious until you look at how most teams work. In The Figma to Browser Chasm (2023) Jim notes that “sometimes a Figma mock is too easily conflated with the end product,” and quotes Derek Briggs: “Users don’t see your Figma files, so they’re only as good as their implementations.” He compares the chasm to Pinterest fail memes, where a beautiful abstraction of an idea meets the attempt to make the thing itself. If the hours and talent sunk into a Figma file cannot be translated into working code in the browser, that money is thrown away. You only capture the full value of a talented designer, he argues, with an equally talented engineer who can read those skills into code, or, if you are lucky, with one person who does both.

He makes the same point from another direction in Making Films and Making Websites (2024), starting from Baldur Bjarnason’s claim that software has more in common with media production than housebuilding. A screenplay is not a film; it is a tool in service of making one. By the same logic, “what you use to make a website is not the website itself.” The only source of truth is the website people access and use. Everything upstream, from design system components to mocks to research data, is in service of that final form. Jim’s worry is organisational: when each discipline pours its care into its own deliverable, blame for the final product gets impersonal (“my mocks were pixel perfect!”) and nobody ends up responsible for the experience of the person who has to use the thing. “People come to use websites, not look at mocks.”

Why is it hard to be the one person who does both? Jim’s answer in The Tension Between Logical Reasoning & Illogical Creativity (2023) is that programming demands logical thinking at every step, and when that demand leaks out of the editor into ideation it becomes a weakness, because it limits your capacity to imagine new connections. He borrows John Cleese’s description of a new idea as “connecting two hitherto separate ideas in a way that generates new meaning,” and locates the value of design engineers in their having built a muscle for holding the two demands in balance. The cost is social. Interdisciplinary Website Maker (2024) describes interviewers who stammer when he says he wants to do design and code, and a climate where cross-disciplinary interest reads as a lack of dedication to craft. He quotes Paul Ford: “The interdisciplinarian is essentially an exile.” His own degree is a Bachelor of Science in Interdisciplinary Studies with an emphasis in Visual Technologies and Spanish, which he says was more graphic design than programming. Websites, he writes, are like trees: you need understanding from every discipline to grow them, and even the title Design Engineer leaves most of those out.

Two older posts explain what the code is for when you design with it. Designing Between the Lines (2021) opens with a line attributed to Matisse, “I don’t paint things. I paint the difference between things,” and ends with the instruction: “don’t merely design things. Design the relationships between things.” In between, Jim quotes Ken Kocienda on why A/B tests can find a button colour that gets clicks but cannot produce a product that feels like an integrated whole. The relationships are what you cannot see in a static frame and what you feel immediately in a running one. The Unseen Work of Design (2021) adds that “the final product isn’t produced but discovered,” through the endless refinement of elements and their relationships, and that when it is done right it feels like the inevitable outcome of where you started.

There is a quieter reason to work this way, and Jim gets to it in Craft and Satisfaction (2025). Quoting Sean Voisen (“Maybe nobody will notice those details, but it doesn’t matter. We care, we notice, we get joy from the aesthetics of the craft.”), he asks where satisfaction in craft comes from and answers: from arriving at a more intimate understanding of the material you work with. When you start out you care about the outcome; keep going and you find yourself caring more about what goes into the thing than about the thing. He thinks AI can run this in reverse, so that you care less about what goes in and only about what comes out, and leaves himself a question: “do I care more or less about what I’ve made when I’m done using AI to help make it?”

For a worked example of design decisions made in code, read Rauno Freiberg’s Crafting the Next.js Website (April 2023). The site was built in February 2023 with Glenn on design and Alasdair, from a design Rauno describes as “no swanky mesh gradients, obnoxious artifical shines, or overuse of gimmicks.” The team shipped the static version as soon as it was an improvement over production and let animations follow, rather than dragging out an already massive pull request. The hero’s blinking switchboard started life as a vector illustration, but rendering was inconsistent across browsers, so he built it in code. That is Jim’s argument in one sentence: the medium pushed back, and the design was found in the material rather than handed to it. Rauno adds that the project filled his creative cup at his day job rather than a side project, and the page ends with a note that no artificial intelligence was used in making it. Read next to Jim’s question about caring, that is a telling note.

What to take into your own work: treat the running interface as the design artifact, not a downstream copy of one. When a mock and the browser disagree, the browser is telling you something about the material. Budget for the poking and tweaking Jim describes, because that is where the relationships between elements get set, and notice which parts of the work you still care about after they are done.