It cuts both ways

July 30th 2026

On a recent project I was brought in to consult on the design side, and to help smooth a conversation that had started to snag. The client had noticed a disjoint ~ things getting lost in the gaps between what they wanted, what the designers drew, and what the developers built ~ and they wanted to know how they might strengthen their web team’s skills across the board. Part of my job was simply to get everyone talking to one another again.

It’s a situation I find myself in more often than you’d think. When I work in a narrower role ~ just the design, just the consulting ~ the same thing tends to surface. Someone will say, half-surprised, “it’s amazing you can design and understand the code,” or, wistfully, “I wish our developers understood a bit more about design.” The division between the two is often so clean, so firmly drawn, that it isolates each side from the other ~ and the workflow is rougher for it.

This always reminds me of that long-running and occasionally heated debate: should designers learn to code?

The trouble with that question is that it only ever runs in one direction. It’s a fair question. My reply would be: yes, absolutely. But this is only half the story. The other half is one I find myself defending most often. Because I believe it cuts both ways. A designer should understand code, and a developer should understand design. This is not to say that everyone should be an expert at both. . Rather, when both sides grasp something of the other’s craft, the work of designing and building something goes more smoothly, and the outcome will be all the better for it.

One thing I most enjoy about the way I work is being a designer whose focus is design, but who’s happily prototyping in the browser, as well as finalising there too. I do plenty of real design work in code rather than only in a drawing. It’s one aspect I most enjoy passing on to my students: showing them directly, via my own work, that the two aren’t separate trades. So let me make the case for both sides ~ and I’ll lean on a chair to do it. A chair is a lovely, honest example of something which is both designed and built, and only worth sitting on when both halves of the craft are done well ツ

Two sketched wooden cross-back chairs side by side, one in slate grey, one in rust orange, facing slightly inward with an empty space between them.
The designer’s chair and the developer’s chair, left mid-conversation. Both still sketching. Both always iterating.

The designer should understand the material

Think of someone who makes a chair. They have to understand the wood ~ which timber takes a load, how to cut a joint that won’t work loose the first time someone leans back, where the grain will split if it’s pushed the wrong way. You don’t need to spend your life at the workbench. But if you’ve never made a joint yourself, you don’t really understand what effect the build or use of the chair will have on the wood. Understanding the material and how it will be worked to be fit for purpose is essential.

Code is the web designer’s material. HTML and CSS are the grain and the joinery ~ and a designer who can build their own design, even as a static, less dynamic version, understands what they’re actually asking for. You might land a design role where you rarely, if ever, write production code. But having prototyped your design yourself, you know what the developers are up against when things get complex or difficult. You will then hand them a head start rather than a wishlist. Every decision you make will be grounded in what the material can actually bear.

The developer should understand the design

Now turn the chair around. The same chair still has to be good to sit in, and nice to look at. Its proportions, its line, whether it invites you to sit or merely holds you upright ~ none of that is structural, and all of it matters. A maker who understands only the joinery builds something sound and functional but graceless. A maker who understands only the look builds something handsome that collapses. The best chairs come from someone who cares about both aspects at once: function and form.

A developer does not have to call themselves a designer. But one who understands colour ~ how a colour scheme is created and applied, why certain combinations sit well and others jar ~ and who has a grounding in a few design principles, makes better decisions the moment a mock-up leaves something unanswered. And mock-ups always leave some small detail unanswered. The developer who can reach for design sense in that gap fills it gracefully, rather than making an awkward guess and hoping. They’re better at the build, and, in my experience, are also a lot happier in the work ~ because they understand the why behind what they’re constructing, not just the what.

This view shapes our teaching

These reasons are exactly why our MA at Greenwich teaches both sides of the craft: design and development. We combine both all the way through, rather than picking one side and merely skipping through the other. Apparently ours is still the only master’s in the UK that genuinely combines design and development ~ not two subjects bolted together, but a single approach that brings both crafts together ~ something we believe makes a good web professional (◠‿◠)

This approach is how my colleague David Watson and I teach. He’s a developer who’s grown into design; I’m a designer who likes to code. When we put our heads together to give feedback on our students’ projects, our students get both angles ~ the developer’s eye on the build and the designer’s on the craft of it. Two lenses on the same piece of work. This, so we’re told, is effective for learning and fostering skills across both design and development.

It’s also why so much of what we make, we make open. My Design for Web handbook and David’s Explainers for Devs are both free for anyone to use ~ because we think this stuff should be learnable by anyone with the curiosity to try, whichever side of the craft they came in on.

If any of this chimes with you, here’s where to find us: