Should web designers know how to code?
I have asked and have been asked this question numerous times over my career. I have very good friends who disagree with me completely on my opinion, and I’m on the cusp of teaching a web design class to unsuspecting, pliable minds and I need to decide – soon – what exactly I’m going to teach them and how. This blog post is my way of working it out for myself. I hope you find it helpful.
When I was in school, I held a digital printing job. This means that it wasn’t traditional offset printing, but more like your typical Kinko’s, quick-print type place. I learned a lot about what you could and couldn’t do to get the highest quality print for your client. You can’t design to the edges. You have to leave enough room around the fold. You have to take into account color shifts. You have to embed your fonts correctly. When I lost this job and found myself without work for a few months between Halloween 1998 and January of 1999 (when I got my first web design job), I did something that felt natural to me, and it turned out to be something I would do every time I found myself without work: I learned something new. Something technical. I taught myself HTML (ok, GoLive CyberStudio helped).
Graphic design has always contained a technical component. There have always been tools that designers use to put their ideas together. For the old timers, these tools included Letraset, Rapidographs, offset printing, choosing the right kind of paper, worrying about dot gain (and many other things I’m unqualified to even list out). For print designers today, these tools have moved to the computer, but knowledge of the output is always required when creating something. Is it a magazine ad? A stand-alone print piece? A newspaper ad? All of these media have different constraints and strengths. Knowing these strengths and constraints isn’t a luxury, it’s not an extra thing, it’s a requirement. You can’t do your job without knowing them.
As a young student who was interested in web design, the language of the web was a natural progression for me to learn. If I wanted to design for the web, it just simply made sense for me to learn HTML. I never wanted to be a web developer, I wanted to be a web designer. Maybe I was just a misguided student, but learning HTML didn’t seem like an extra thing, or a luxury, it felt like a requirement.
I think I still feel like it is today.
Your first instinctual reaction (as mine would be), is of course going to be that learning HTML is not learning web design. And of course – of course – that’s true. Just because you know Flash or HTML does not mean you’re a designer. I would never be brain-dead enough to suggest such a thing. The visual and strategic aspects of design are always more important than the technical ones – it’s just that the technical skills should exist alongside all of that to effectively uphold your decisions. This has been true of design as a discipline for decades.
But if you’re a web designer, think about it. Think about who you admire most. Dan Cederholm? Neven Mrgan? Jason Santa Maria? Jason Fried? Shaun Inman? Jeffrey Zeldman? These people all know code, even if they don’t do it on a daily basis. They all understand the importance of designers understanding what it is that makes their designs real. I’ve never been comfortable with what I create being dependent on someone else to become fully-realized. I’ve never been comfortable spending my time dreaming in design-land where my ideas are the only important thing, and making them work in the real world is the least of my worries. That feels irresponsible and arrogant to me.
My friends who disagree with me say at this point that if they’re spending time worrying about the implementation, then they’re not spending time worrying about solving the problem. Which again, I just don’t understand. You can spend all the time in the world on wireframing to get the right flow down. You can spend a million hours pushing pixels in Photoshop to get the client happy and to get sign off. But when that’s where design work ends and where development begins, I have always found that the end-result is unimpressive and not exactly what I had in mind. Just because a Photoshop file exists somewhere in the ether of your hard drive doesn’t mean that the real thing – the thing your users are going to use – is just as perfect. If you leave that translation up to someone else, almost 100% of the time, it’s not going to be nearly as perfect as your precious PSD. And then your work has been for what?
The next step in the conversation usually requires me to say this: No, you shouldn’t have to code everything all the time. Maybe you don’t need to learn PHP or Objective-C or Ruby on Rails or SQL or anything that runs on a server or gets compiled. Although I can tell you that I do know these things, and even when I don’t write them for what I’m working on, I always make use of that knowledge when designing to make use of them. Overlapping skills on a team is obviously a positive thing. You don’t have to write all of the code for your web project to be able to leverage that knowledge to your advantage. How can more knowledge about your field be a bad thing?
How can you know that fancy interaction design you’ve storyboarded in Illustrator is the right one and feels right to use unless you create an interactive prototype to test it out? Why wait for someone else to do it for you? Why not just learn how to do it yourself? Because it’s hard? Because it doesn’t feel like doing design? Because you just don’t feel like learning how?