Do designers need to code? This has been the question of the moment of late. Though, speaking of late, I may have missed the main period of discussions around the subject. Regardless, here’s my take… Disclaimer.

Is a web designer really a web designer if they can’t code?

A lot of the arguments revolve around the (false) fact that ‘designers can’t understand what they’re designing if they can’t build it’. This argument suggests that a web designer who can’t code is a fake who’s just blagging their way if they don’t know/understand how to actually build the websites they design…

This is wrong. By this token I should understand MySQL and programming and Project Managers should understand design theory and programmers should be able to manage clients. There’s a reason we have different job titles; people do different jobs.

A designer who can build websites is a designer–developer, a designer who can’t write HTML/CSS is a designer.

Designers should work with developers

One reason, I think, that people believe that designers should be able to code is that they need to honour their designs, they need to be sure their designs are buildable by being the ones who have the responsibility of building them.

The problem is not that designs need to be buildable, it’s that developers should be permitted to send designs back and make compromises. Designers and developers need to collaborate, not be combined. Designers need to keep pushing the envelope, making tricky and outside-the-box visuals that push the work of the developer forward. The developer needs to be able to work back the other way, show the designer the boundaries that cannot be broken. Designers shouldn’t lead developers, developers shouldn’t lead designers, there should be a happy middle ground where teams work together, specialising in their respective areas but understanding and appreciating each others’.

A designer who codes badly is less use to a developer than a designer who can’t code at all. Developers need designers, not bug making machines.

But the client was shown a PSD that needs to be honoured…

I think this may well be one reason why people believe designers should code; the situation where the client has seen a PSD and thus expectations are set. A developer hasn’t seen the visuals and is all of a sudden expected to build something he’s had no input in. For the most part this may not be the case at all, but it definitely could be…

The remedy here might be to make sure designers only create things that they can build, achieving this by making sure designers can code.

This is fixing the wrong problem, the problem here is a lack of communication and a lack of collaboration, not a lack of skills. Designers and developers should work together from the outset, working in the browser to ensure that a) the team is working as, well, a team and b) that a client is never shown a PSD (showing a client a PSD in 2011 is just foolish).

The recurring theme is collaboration… Designers and developers need to coexist, not be one and the same.

HTML and CSS isn’t easy…

…but it is easy to do badly. I know loads of designers who can make the most stunning visuals but their code is not a strong point. Sure, they can write HTML and CSS, but it’s not where they specialise or excel, in much the same way a lot of developers have no design sense.

A designer who writes bad code is less use than a designer who can’t code at all. Once a designer writes poor code then either a) a decent dev has to come along and spend time bug fixing, or b) poor code becomes a tangled mess off spaghetti CSS and browser hacks.

Do not undervalue the importance of HTML and CSS, they are easy to do badly, but hard to do excellently. You need excellence in both design and development, so leave each role to its respective person.

These rules introduce restrictions

If a designer needs to code what he’s designed then he’ll design to what he can do, not to what can be done. This is a fundamental mistake to introduce.

A designer who isn’t restricted by a secondary skill set will produce things outside the box, push the envelope and keep innovating. A designer who is limited by their dev knowledge is hemmed in, scared of pushing the boundaries for fear of creating themselves work they cannot complete.

By forcing one thing you are restricting another, this is not a good thing to bring into your team. What you need to do is keep the contact and collaboration (there it is again) between design and build to ensure that everyone is achieving their full potential.

Real life examples

I know two people, personally, who both excel in their given fields. One is a fantastic designer who constantly produces unconventional but stunning websites, the other is an incredible front-end and JS developer (among other things). The designer can write code, but it’s not his focus, he doesn’t write production code because the developer does that.

They have a dynamic working relationship whereby they collaborate (and again) and consult with each other throughout the whole project. The designs look incredible and they’re built very well. This is more valuable than a constrained designer forced into producing buggy, poor code to build designs they’re not fully happy with.

What do they need to understand?

If a designer doesn’t understand code then this is fine; they don’t need to understand code, they need to understand their medium. Having an understanding of the web is not the same as being able to build it.

A good designer working with a good developer is a team that is good at making websites.

Don’t dilute someone’s skill set by trying to expand it, play to the strengths of your team. Designers who can code do exist, but they don’t have to. If you are a designer who can code (and thus a designer–developer) then that’s great, if you’re a designer who can’t code, but work well with developers that can, then great!

But there is no right or wrong answer

Designers can code, sure, but they didn’t ought to be required to. No one should be saying that a web designer isn’t so because he can’t code, that’s actually pretty rude…

If you have the budget to hire two people then get yourself a designer and a developer. Your designer doesn’t need to be able to code, they just need to work well in a team.

However, if your budget dictates you can only hire one person then hire someone who is a designer and developer. If you need to hire a designer–developer then make are they’re sufficiently good at both. If you can only hire one person then your designer does need to be able to code.

Designers do not have to be able to code, no one can make such a sweeping statement. It depends what you need, what you are comfortable with, and what works best for your team.

Massive disclaimer

When I say designers and developers I’m separating people into two camps; designers (people who just design (people that the industry seem to have a problem with)) and designer–developers (people who design and code (the people the industry expect)).

I’m not saying designers write bad code, because a designer who can and does write code is a designer–developer. Designers are, by definition, people who don’t write code.

So if you are a designer and you think I’m saying you can’t write code when you can then I’m classing you as a designer–developer. If you’re a designer who can’t code then that’s great. Please, no one take any offence, because none is intended.

In short

Designers shouldn’t have to be able to code to be called designers; designers should be able to collaborate and understand the rest of the team and vice versa.

If you need a designer–developer then yes, your designer does need to be able to code. If you can afford a designer and a developer then they don’t.

As David Kaneda so rightly put it:

“Just a thought: Devs don’t need to learn design, designers don’t need to learn programming — people need to learn how to collaborate.”

A little background

N.B. I am in no way saying we invented the concept of designing in the browser, we merely adopted it very early, before most.

I have championed designing in the browser long before it became popular. True fact. I was doing this long before it was a mainstream practice.

When working at Sense I was extremely lucky to work alongside a man called Philip Meitiner. He was Sense’s Account Director and a genuine pleasure to work with and learn from. It was whilst we were working on a white-label website for some big name clients (Nissan, Renault, Mercedes, Volvo and more…) that we decided to ditch Photoshop and dive straight into the browser. This idea was born from the fact that I’d put together a series of HTML wireframes whose code was of a quality that I deemed suitable for production. It seemed backward to us to then fire up Photoshop and design an image based on a set of HTML pages, to then return to the HTML and style it.

Thus was born our idea to design in the browser. We saved the HTML in isolation and used it as a starting point for each development of the various sites we had to build. We branded and designed each white-label in the browser and sent live, actual code back to the client for approval. It was, for everyone involved (though me more so) a dream come true.

The article I wish I’d written

Months later, 24 Ways published their article on designing in the browser. If there was one article I wish I’d written, it’s that one. Phil was equally dismayed, however at least we knew we were on to something good.

How it works

For those not in the know, designing in the browser is exactly as it sounds. Instead of building a website in Photoshop then markup, you dive straight into the browser and notepad and get cracking. A few benefits:

• Saves time, cutting all Photoshop work.
• Changing repeated elements (e.g. hyperlink colours) takes just one CSS declaration in the browser. It takes a lot of donkey work in Photoshop.
• Clients buy websites, not printouts of websites. Designing in the browser allows them to see how their site looks in its intended environment.
• This makes progressive enhancement usage much simpler. If they view it in Chrome, they see your round corners. If they view it in IE they see square corners. Both are intended behaviours, and both are fine.
• It can show things like hover effects and interactions that Photoshop can’t.

“Clients buy websites, not printouts of websites.”

How it improves build quality

There are a few reasons why I believe that designing in the browser improves the overall build quality of a website.

Users don’t (generally) visit a website for its design, they visit for its content. Designing in the browser considers content first. This is absolutely essential for a well thought out website, in my opinion. In Photoshop you design a layout and then populate it with content. Designing in the browser you start with your content and design around it. Content is the focus and the design does nothing but complement it. You’re coming up with a suitable way to house the content you’re starting out with, rather than shoehorning content into a preconceived design.

By focussing on what your users are actually coming for, you often find that a better UX will follow. Ignore anything extraneous to begin with, nail the fundamentals (hint: typography!) and concentrate on how pretty it looks after. Designs change more frequently than content does; invest in the content early.

“What happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?”

Another reason is that, particularly if you are in a team where the designers don’t do a lot of hands-on coding and build, devoting a lot of code to purely visual effects and design can lead to insensible builds, insemantic markup and a whole host of other issues. This is, admittedly, a marginal chance, but coding around the content before the design will often lead to more sensibly built websites, focussing more effectively on its content.

The main time to use the designing in the browser as your primary build method is probably with a lot more sites than you’d imagine. Blogs, ecommerce, portfolios, news sites, apps, aggregators. You name it.

Designer to developer

Hopefully this one doesn’t happen often, but it can do…

I’m sure developers have had this countless times–a designer brings you a design that just isn’t codable. The client had been shown a PSD that you have no hope of coding unless you botch and hack at markup and use ridiculously extraneous amounts of Javascript to manipulate it. By designing at code level you avoid all these problems from the outset. What you code is your design, your design is codable.

Designers obsolete?

Far from it. The designer is often the developer anyway, and if not, the designer is needed to call the creative shots and create initial visuals. Take Venturelab for example. Si came up with the skeleton of that design in Photoshop. Any type work, any calls-to-action, lists, navigation and tables were done by me, in the browser. Si created two ‘mood board’ style PSDs (and very good ones at that) but Justin was only ever shown working code, designed in the browser.

Nail the backbone in Photoshop if needs be, but in areas where rapid development and the need for quick and arbitrary changes are needed (think typography and link colours etc.) designing in the browser is far more efficient. Imagine the pain of changing the zebra-stripe colours of a giant table in Photoshop when you just edit one CSS declaration and see to it all in one go.

On pushing the limits

There have however been one or two occasions in my career where not designing in the browser has done more good for a project than bad.

“There’s a large chance that [a developer working in the browser] won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.”

The first example links back to what I said about designers handing sites to developers that the developers can’t code. If the person designing the site is also the person building it, there is a (pretty large) chance that they’ll take the easiest simplest route to completion. There’s a large chance that they won’t make things difficult for themselves, that they won’t push their boundaries. This is a bad thing.

If I draw on my own experience, the Findus Crispy Pancakes site is an excellent example of designers giving developers the kind of headaches we love. I built Findus about a year or so ago whilst at Sense. Rob designed the site in Photoshop and when I saw it I nearly fainted. I had no idea where I’d even start coding up such a complex looking, overlapping, quite frankly mental design.

Yet despite this, I got my developers brain on and got to work. I finished the site about four days ahead of schedule and enjoyed every minute of it. That design pushed me more than it would have if it had started out in the browser. It was a lot better for being in Rob’s hands first. And I still maintain that it was one of my most challenging builds to date (IE6 support…).

Developers still need designers!

Follow Rob on Twitter. Fantastic designer and all-round nice guy.

It is important that the designer and developer have overlapping knowledge of each others’ respective areas, yet play to their fullest in their own. The Findus site was a bit of fun on a small project which allowed me and Rob to really stretch ourselves, and that’s what it’s all about.

Big brands

Another couple of times where designing in the browser hasn’t been viable was when we, at Sense, were working on the Travelodge and Rizla websites. Travelodge was designed by another agency anyway, but even so, as they had very stringent brand guidelines that stated that round corners were a pivotal part of the brand, everything needed to be done in Photoshop.

Another example would be Rizla, which, again, we built at Sense. As Rizla’s brand is so important to their success and recognition it could not have just gone straight into the browser. Rizla wasn’t so much about quickly accessible content, so much as heavily designed and branded content. We allowed for users to change the design, and for the design to carry off promotional work, which could not have happened straight in the browser.

Aiding programmers

This section was edited in part by Dan Bentley.

Programmers manipulate markup. A Photoshop document is nigh on totally useless to a programmer, whose involvement lies in all that magic stuff that happens behind the scenes. Allowing programmers access to the code from an earlier point means they can start their job alongside the developer sooner.

Furthermore is the idea that Javascript developers can visualise their involvement much sooner, too, and see what markup they will be manipulating from the outset, rather than having to second guess what markup might result from the developer’s take on the PSD. They can start manipulating the DOM and begin building prototypes alongside the main build developer right from the start, making life easier for them as well.

When do you design in the browser?

At every available opportunity.

It saves time, it’s a much better way of presenting concepts to clients, it leads to better quality builds, it gives more consideration to content, it’s more fun than working in Photoshop (at least from my point of view), it’s easier to experiment, it’s far more efficient and the quality of the code is usually better as it concerns itself with content over decoration.

“Designs change more frequently than content does; invest in the content early.”

For any content-centric sites (I know, all sites are about content) such as blogs, web-apps, CMS style dashboard builds, news sites, informational sites or anything similar, you can’t lose by designing in the browser.

If you’re an account manager type person at an agency, run the idea past your development team; I’m pretty sure they’d love to work like this, if they don’t already.

When can’t it be used?

Sometimes, designing straight in the browser just can’t work. Heavily branded or very graphical sites that are more about decoration or branding than content will be a struggle to create without opening Photoshop first. However, by completing the major chunk of the layout and graphical design in Photoshop, you can often leave it at that, and model/work on type straight in the browser (what happens when your Photoshop printout uses nice anti-aliased Helvetica, and the final site renders in non-aliased Arial on the client’s machine?). For the fine details, designing in the browser will be far more efficient and true-to-life than using Photoshop will ever be. Embrace it, and enjoy it.

Final word

So, do you design in the browser? Are there any reasons why you don’t? Would you like to? Leave a comment and open the debate up a little wider…

Also, follow Suze on Twitter.

As the site was built very quickly, we are adapting it as it grows and fixing any bugs as they happen. Let me know if you find anything astray. Anyway, enough talking, go look for yourselves!

Many hands make light work

There are lots of contradictions in sayings and phrases. Like this one, if many hands do make light work, then how does this next one work?

Too many cooks spoil the broth

A stitch in time…

While the cat is away…

Absence makes the heart grow fonder vs. time is a great healer

This one is another glaring contradiction, so I decided to combine the two into one poster.

Out of sight, out of mind

Two wrongs don’t make a right

This one doesn’t really follow the code paradigm, but I thought I’d include it anyway.

Got any more that would work in this way? Leave any suggestions in the comments.

Also, I do realise that, programmatically, not all of these posters make perfect sense. For example, $cooks > 'enough' doesn’t really work in a programming sense… It’s just a bit of fun!

Typographic work planner markup:

The rich, semantic markup is as follows. Notice the use of the more semantic elements and attributes such as summary="", colgroup, scope="", caption and more…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

  <title>Typographic work planner</title>

  <link rel="stylesheet" type="text/css" href="css/style.css" />
</head>
<body id="home">
  <div id="wrapper">
    <table summary="An overview of upcoming and recently completed work ?
    by employees">
      <caption>Work schedule</caption>
      <colgroup>
        <col id="date" />
        <col id="user" />
        <col id="dec" />
      </colgroup>
      <thead>
        <tr>
          <th scope="col">Date</th>
          <th scope="col">User</th>
          <th scope="col">Description</th>
        </tr>
      </thead>
      <tfoot>
        <tr>
          <td colspan="3">Sense Internet Ltd work planner</td>
        </tr>
      </tfoot>
      <tbody>
        <tr>
          <td class="date">20 December, 2009</td>
          <td class="user">Harry Roberts</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr>
          <td class="date">20 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Harry Roberts</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr>
          <td class="date">21 December, 2009</td>
          <td class="user">Sam Penrose</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Sam Penrose</td>
          <td class="desc">Lorem ipsum dolor sit amet, elit. Nunc ?
          rhoncus dui et mauris. Nam augue felis, dapibus ut, condimentum ?
          in, ornare a, est. Proin sem risus, pretium ut, mattis nec.</td>
        </tr>
        <tr class="today">
          <td class="date">22 December, 2009</td>
          <td class="user">Joe Whitley</td>
          <td class="desc">Suspendisse venenatis. Donec eleifend ?
          dignissim diam. Integer faucibus neque tempor pede. Maecenas at ?
          magna sed lectus adipiscing molestie. Pellentesque habitant morbi ?
          tristique senectus et netuset malesuada fames ac turpis egestas. ?
          Curabitur sodales gravida tellus.</td>
        </tr>
      </tbody>
    </table>
  </div>
  </body>
</html>

In detail…

There are a few things in the table you may not have seen before, briefly, they are:

• summary="": This is an attribute which provides a brief overview of the table and its contents/purpose.
• caption: This is a table specific caption, essentially a heading/title explicitly for the table.
• colgroup and col: This is an essentially invisible element that just adds semantic meaning to the table. It defines the columns and can—in some browsers—be used to style them.
• scope="col": This is an attribute which tells the browser whether the th is a title for a column or a row. This then obviously makes the other possible attribute value row.
• tfoot: This is a table footer and contain pretty much anything you like. It must however appear before the tbody.

Typographic work planner CSS:

The CSS used to create the work planner is pretty basic, with a dash or progressive enhancement added via some CSS3. View the full CSS file with reset etc.

table{
  margin-bottom:20px;
}
td,th{
  border-bottom:1px solid #ccc;
}
tbody tr{
  background:#fff;
}
tbody tr:nth-of-type(even){
  background:#ffc;
}
th,tfoot,caption{
  font-family:Helvetica, Arial, Verdana, sans-serif;
  font-size:1.6em;
  font-weight:bold;
}
th,td{
  padding:10px 0;
}
caption{
  font-size:2.4em;
  position:absolute;
  left:-9999px;
}
.date{
  width:160px;
  padding:10px 15px 10px 5px;
  font-family:Georgia, "Times New Roman", Times;
  font-size:1.6em;
  font-style:italic;
}
.user{
  width:460px;
  padding-right:20px;
  font-family:Helvetica, Arial, Verdana, sans-serif;
  font-size:4.8em;
  font-weight:bold;
}
.desc{
  width:280px;
  font-size:1.2em;
}
tbody tr.today{
  background:#ff8;

  text-shadow:1px 1px 1px rgba(0,0,0,0.3);
}
tfoot{
  color:#666;
}
tfoot td{
  padding:10px 5px;
}

Typographic work planner demo