Professional Web Designers Code. Don’t They?
To be code literate, not necessarily a “coder”.
This is one of those hot-button topics that resurfaces every now and then. It invariably polarizes designers and developers, perpetuating the ‘Us’ and ‘Them’ mindset, and twisting more than a few knickers in the process.
My intention is not to further twist anyone’s britches, I am after all one of You, and Them. Yet many of us impose arbitrary “rules” to our role as designer which as I will explain is, essentially, nothing more than a half-assed attempt at avoidance.
There’s a persistent mindset amongst some professional designers to compartmentalize (or flat-out ignore) those aspects of the Web building process that are difficult, uninteresting or unpleasant because they don't consider it to be part of their “job” as someone who designs and builds websites for money.
Take for example the core argument,
Web designers should know how to code. What exactly does it mean? How is the term ‘Web designer’ defined? In what context is it being used? Code what? A 3-page brochure site? The next Amazon? A couple lines of CSS? Is the implication that every designer should hand-code? To me the most common and yes, incorrect assumption. Or are we saying a designer should be code literate?
A Little Context
Let’s begin by stating the obvious:
Clearly not everyone who designs and builds websites does it for a living. So even though this article focuses on professionals I hope it serves as food-for-thought for anyone of any skill level.
“Web designer” is often used as a parent term to encompass the roles of ‘designer’ and ‘front-end developer’, and for the purpose of this article it’s a distinction I’ll use.
Now, I realize some of you have jobs that require highly-specialized skillsets so the technical demands of your daily work is likely much more focused on a particular aspect compared to the broader approach I describe below. It’s not a matter of better or worse, it’s just different.
At the opposite end there are those of us who move back-and-forth between the roles of designer and developer as needed, as such not everyone defines their role as one or the other. In some circles these people are referred to as ‘Unicorns’.
It’s not a term I particularly care for since it implies a mythical creature, and I for one am not mythical according to my last reality check. Nevertheless it refers to a large number of designers/developers despite the insistence by some that I (and you) can only be proficient at the design/artistic or the technical. To that I call, “Bullshit!”. But that’s a topic for another article.
Defining ‘Designer’ and ‘Developer’
I’m referring to professional freelancers/contractors for whom building websites is their profession and primary source of income.
- Why only professionals? Presumably a professional has a greater need to stay current with technologies, techniques, trends, skills, tools etc.
- Why only freelancers/contractors? Typically this is a one-person operation, as such they are (usually) solely responsible for how the site looks and functions, compared to a company with say, a team of specialists.
This person would be responsible for the entire design and development process. Meaning they do not mockup a layout then hand it over to a developer to code, but instead build it themselves using their preferred method or tool, be it hand-coding, a visual design app or a combination. Also, I’m only referring to front-end designers/developers, not the back-end crowd.
Part 1: Looking Back
When I got into this the skills that defined ‘designer’ and ‘developer’ seemed, at least to me, more clearly drawn than they are today. Web designers were often re-purposed graphic designers trying to graft their print sensibilities onto the often slippery and fluid Web medium, or they were “visual types” who wanted in on the Web game. Whereas developers possessed skills specific to the Web environment. For many of the so-called “visual” designers the only way around the technical learning curve was and still is the What You See Is What You Get2 app.
While probably not the wisest decision it was for many of us — including myself at the time — easy to remain ignorant of the technical vagaries of Web design by hiding behind the WYSIWYG facade. What made it even easier to turn a blind eye was that many of us were building very basic static brochure (maybe some light e-commerce) sites for desktops which wasn't all that technically challenging. On top of which there wasn’t a deep level of interest, discussion or understanding about code by the visual Web design community at large. Nor was there the far-reaching awareness of the importance site metrics play in the bigger picture. There was so much we didn’t know.
Yet despite all of our self-imposed handicaps it seemed if you could point-n-click that was enough to call yourself a Web designer and start hocking your “skills” for a pretty-penny. Looking back it was a ridiculously easy time to be a Web designer, at least a certain type of designer. In some ways things haven’t changed.
For those that aren’t familiar WYSIWYG was/is an attempt to port the familiar desktop publishing (DTP) paradigm — that so many graphic designers were already familiar with — over to the Web authoring world by abstracting the user away from code with a code-generating application and a graphic user interface (GUI), thus making the website building process quicker, more user-friendly and more palatable to non-coders. While this approach can definitely make for a more pleasant experience these apps aren’t without serious technical drawbacks.
Yet WYSIWYG was, and in many ways still is, a very successful model for a subset of designers mainly because it lowers the bar of accessibility thus allowing anyone of any skill-level to get into the Web game. While these tools have a very broad appeal, usually to non-coders, they also make it easy to avoid the responsibility of learning the trade from the bottom up, plus it fosters a dependency on the software to ‘think’ for them. Most people are lazy enough by default, often to our detriment, we don’t need further encouragement.
Even though WYSIWYG tools are often marketed to a more visually inclined user, a person’s choice to use one does not necessarily mean they are less technically skilled or knowledgeable, or code-phobic. I know of highly-skilled coders who for a variety of reasons prefer to use these tools in their work, at least for prototyping or mockups. Our choice of tool does not in and of itself define our skill-set or abilities, but our knowledge certainly does.
Part 2: The Here and Now
Fast-forward to today and the landscape has grown more technical, complex, and challenging.
With the near ubiquitous use of Content Management Systems (CMS) websites are more Web application than simple static HTML. Web performance metrics factor heavily into search ranking so we need to better understand how to optimize our designs “under-the-hood”, and that doesn't even scratch the surface of what we need to be aware of these days. The world has gone mobile crazy with responsive design and the list goes on and on... and on. Is it design? Is it development? On whose shoulders do all of these new challenges fall? Short answer: It’s both and it’s your responsibility.
Software may simplify some tasks but it doesn’t mean we’re learning anything about how a website functions, or the best way to design and build it, which seem like absolutely fundamental requisites for a Web designer. Yet many choose to live in a state of arrested development.
But software is simply a tool, and there are all kinds of tools. Code is another one. What makes them useful and effective lies in our willingness and ability to learn how to use them so we can leverage their power. Even the ones we don’t like, or are scared of, or not interested in.
It’s Not My Job
Yet there remains a persistent mindset among some designers that code literacy is not their responsibility so they treat it as an afterthought, at best. As though their lovely pixel-perfect layouts are not inextricably tied to the underlying code. Or perhaps they think ‘design’ is only about how something looks when in fact it has everything to do with how it functions. You can thank Steve Jobs for that pearl of insight.
Part of the problem with some of today’s Web designers is the same as always: they still think and work as (albeit talented) graphic/print designers. They design a pixel-perfect static mockup in Photoshop or Illustrator3 with little or no understanding of whether their meticulously crafted layout is possible or practical in the fluid Web medium; that it can even be built to work consistently across a huge number of platforms, devices and resolutions. Who cares about code soup, semantics, best practices or Standards? You’re a designer, not a coder. It’ll be fiiine.
To me the best designers understand how to bridge the gap between a pixel-perfect design and real-world implementation before it ever gets to the development stage.
Being functionally literate and communicating in the language of the medium is a reasonable expectation for our peers and clients to have of us. Or to put it another way:
How can anyone effectively build (or fix) something… anything, when they ignore their tools and/or don’t understand how or why it’s constructed the way it is?
There Is No Spoon
Obviously the areas of design and development require different skill-sets, nevertheless Web designers and Web developers don’t exist in their own vacuum. We may refer to ourselves as one or the other, and we are probably more skilled at one than the other. Hell, we probably like one more than the other. But I suspect for many (or most) of us those distinctions blur in the real-world where the hands-on reality is rarely so clearly defined and tidy.
Designing and building for the Web requires a willingness to step outside your comfort-zone. The Web is constantly evolving and so must its builders. The days of development skills existing at the opposite end of the stick from design is, to varying degrees, effectively over for many of us. Of course we still need specialists, we always will, but for many freelancers the job requires a broader more comprehensive understanding of the medium.
The well-worn mantras of “I don’t care about code” or “I don’t have time to learn code” are at best short-sighted, and at worst serve to undermine the quality of the end-product. Nor are they remotely valid arguments, they’re excuses.
Remember, we’re talking about professionals. Yet these same people don’t know what a CSS selector is? C’mon.
A code literate designer is better equipped and prepared to adapt to a rapidly changing environment. It makes us better problem-solvers and gives us the tools to produce a higher-quality end-product for our clients. But more than that it’s our responsibility to earn the knowledge for ourselves.
It’s often said the difference between an amateur and professional is the professional gets paid. Ok, but certainly money isn’t the sole determining factor. Our experience, skill and knowledge must play the biggest role in how effectively we do our job, and how our peers, clients/employers perceive our professional competency. It’s not about knowing everything about everything, it’s about constantly pushing for those incremental gains of knowledge and skill.
Would you honestly and willingly pay any professional contractor (electrician, carpenter, plumber, engineer... or designer) thousands of dollars to build or fix something if they told you they chose to ignore an aspect of their trade because they were too busy to learn how it works, or worse because it didn’t interest them?
Whether you’re a designer or developer... or Unicorn, isn’t it our responsibility to understand our job as thoroughly as possible? We’re building the Web. It’s what we do and why we get hired... and paid. Is that not enough reason to take responsibility for our work?
1 Of course there are many other possible scenarios, but this is a common one.
2 Commonly referred to as WYSIWYG.
3 The fact that in a responsive World some designers still build static (graphic) mockups instead of using HTML/CSS is astounding.