It cuts both ways

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. My clients had noticed a disjoint. Details were getting lost, gaps started to show between what they envisaged and wanted, what the designers created, and what the developers built. They wanted to know how they might strengthen their web team’s skills and improve their workflow and communications. Part of my job was simply to get everyone talking to one another again.

It’s a situation I find myself in quite often. When I work in a narrower role ~ just design, just consulting ~ the same thing tends to happen. 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 stark, so firmly established, that it isolates each side from the other ~ effecting the project’s workflow.

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 seems to run 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, the conversations flow better and the outcome will be all the better for it.

One thing I most enjoy about the way I work is being a designer with a clear focus on design, but also being someone who will happily prototype in the browser, as well as finalising there too. I do plenty of real design work in code rather than only in via sketches or graphics app. 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 ツ

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 being able to code your design prototype yourself means 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 comfortably or whether merely holds you upright ~ none of that is purely 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 and understands the basics of good typesetting, 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 for the best. 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 combines design and development across the programme, in theory and practice. We don’t bolt two subjects together, we have 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 these skills should be learnable by anyone with the curiosity to try, whichever side of the craft they come from or want to pursue.

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

• The MA itself, now welcoming applications for the next academic year: Web Design and Development, MA
• Our programme hub: maweb.design
• David’s Explainers for Devs: explainers.dev
• My handbook, Design for Web: designforweb.org