Choosing the right tool

It’s rare these days that something pulls me out of the woodwork to write something here on Stopdesign. A few recent posts by Jason and David at 37signals (Why we skip Photoshop and Web designers should do their own HTML/CSS, respectively) got me thinking though. This post began as a response on an email thread at work. I’m expanding it here to a wider audience.

On starting in HTML/CSS, rather than something else… I’ve tried this several times. Starting with code is favorable in some situations. Especially when the interface is somewhat simple and the layout complexity is unlikely to change. When done similar to how Jason advocates: starting with a few paper sketches or prototypes, then moving straight to code, this can work really well.

However… I consider myself fairly competent in HTML & CSS. But even I am limited in design by starting with code before having a few design ideas fleshed out.

I have advocated in the past that HTML and even CSS are not design tools. They are tools used to implement design. There’s a big difference.

By design tools, I mean anything you can use that feels like a natural extension of your own hand. Be that physical objects like pencil/pen and paper, or software like Photoshop, Fireworks, and Illustrator. Ideally, design tools should allow complete freedom for creativity. They should also allow direct manipulation of the design, without having to think abstractly about how to render the design based on tool limitations.

Jason and his colleagues at 37signals don’t skip the design tools. They still use quick sketches on paper to start. They just don’t rely on Photoshop as a tool that they need to envision a design.

In a comment on Jason’s post, Jeff Croft asked if this no-Photoshop practice of going straight from sketch to HTML/CSS influenced 37signals design style? My answer: 100% yes, it absolutely did. I think it’s obvious when you view their apps. (Not that this is a bad thing.) This practice works well for them. But it certainly influences (and possibly limits) their design style. For them, this is acceptable and appropriate, and it may be for you too. Everyone works differently and has different goals and priorities for design.

Speaking from experience, I know there are designs I created (and coded) that would not be the way they are if I had gone straight to code. In fact, this is how and why I created several new CSS techniques back in the day — out of necessity. An idea existed in a static design somewhere, and I wanted a way to recreate that design with optimized and accessible code, without compromising the design. So I had to invent one.

If you start with code, you will be limited by what you know you can do with code. Whether you’re a code noob or a code snob. Because it’s just that, code. It’s a tool intended for implementing design, not necessarily one for creating design. If you start with a familiar design tool, you know sky’s the limit — anything you dream of, you know you can create or render without thinking about it too much. Starting in code, you’re immediately restricted by tighter bounds of possibilities.

For evidence of this, browse through the CSS Zen Garden. I can tell which contributors started with a few sketches and some form of design tool first, and which contributors started directly in code. It’s obvious after you’ve seen enough designs.

New designs, new techniques, and even additions to the W3C CSS standard would come about much less frequently if we settled just with what we knew code can do. Or what’s been done before. To foster innovation and creativity, design sometimes needs to be divorced from the restrictions of its implementation.

That said, there’s value in not sticking with design tools for the entire process. Especially for the Web, it makes sense to flip to implementation tools at a mid-point in the design process. At a certain point, more work in Photoshop or Fireworks is just fuss. And could be done more quickly and more efficiently in HTML & CSS. Just a matter of determining where that flip should occur — and it’s different for each design team.

This brings me to David’s post, “Web designers should do their own HTML/CSS“. I mostly agree with what David writes. I just wouldn’t be so dogmatic about it. As I was building a Visual Design team at Google, I wasn’t necessarily looking for designers who knew how to wield HTML & CSS like a Jedi wields a lightsaber. After all, Google has an army of engineers to write code, and a very specific way of writing it. Rather, I wanted a team of people who could design and create, first and foremost. I wanted them to have some knowledge of the web’s limitations. However, I stopped short of expecting that they could or would code any design they created. I can teach a designer HTML and CSS anytime. But I can’t teach someone how to be creative with design.

I’m not going to feel bad if I start with a tool that feels more comfortable to me during the creative process. Nor will I shame any other designer I work with for the same. Especially if other tools limit creativity. In any design medium (print, web, interior, industrial, fashion, even architectural design…), I would not be a true craftsman until I intimately understand how my design gets produced and the materials needed to do so. This most importantly includes the innovations and compromises that need to happen along the way because current production techniques can’t recreate my design.

When starting any design, choose the tool (or set of tools) that’s not only right for the job, but also right for you.

Update: Other responses to 37signals’ posts I’ve seen, that probably say it better than I did:

• Jeff Croft: Why we don’t skip Photoshop
• Jon Hicks: Graphics Editor or Text Editor
• Nicholas Rougeux: Why I use a print program for web design
• Mark Boulton: Design isn’t about tools