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
I totally agree, Doug.
It’s also worth noting what we are throwing under the umbrella of “design”. I would guess that design at 37signals is very different than design that some of the rest of us do (that being more commercial in nature). They are essentially building interfaces first, and websites with visual brand attributes second. As you alluded to, this looks like it influences the design of their stuff heavily. I think their stuff works and looks great, but I also think that’s an important distinction to make.
And, it was a nice surprise seeing a new post from your site pop up in my feed reader :)
Maybe what we really need is a new tool that combines the benefits of html/css with the creative freedom of Photoshop/Illustrator. Something built from scratch specifically to design websites, handling page fluidity and paths of interaction between pages.
File > Save As > Website Protoype
Spot on Doug. Each to their own. Most people fear photoshop: openly or in the quiet of their room. And those that know how to use it(Photoshop), do so very well. It not everybody’s breakfast :) and that probably is a good thing too. :)
Minutes after I posted my take on this topic, I spotted yours. I think what’s most interesting (and pleasing) about all these posts is how we all essentially agree to disagree. We all choose the tools that work best for us and respect each other for doing so.
I’m not sold on the idea that designers should do their own HTML/CSS (even though I do it myself), but having some knowledge of what’s possible with it is vital.
“Each to their own.” That’s something we’ve always said and will always believe. Our post wasn’t suggesting anything about what you should do or must do or have to do — it was simply about what we do. Your mileage may vary. There are lots of ways to do lots of things.
Hi Doug, I was glad to read your post. the 37 signals’ post yeaterday left me pretty disturbed (even though I totally respect them and their work). And you’ve really put the points across so well. I’ve faced similar problems at work specially when working with project managers who are engineers and do not see the need to spend time on Photoshop; and you have a great point there, it does show starkly in their work.
@Jason Fried and all still reading:
This response wasn’t intended as criticism of 37signals or any certain design style. Jason’s post was well-written and simply very thought-provoking for me. If anything, David’s post title was a little beyond what I would have written. But David and I are different people with different views. That’s cool. I still basically agree with most of what David wrote too. Other than that, I find the different perspectives and approaches interesting to see documented. And I’m glad Jason and David wrote something that got me interested enough to write again myself.
This sentence caught me in tears. Well, almost. Can I just simply thank 37s for getting Doug roll?
I agree with József – anyone who manages to lure Doug out of the woodworks deserves praise for that reason alone. :)
Doug, you’re back! Those two 37signals posts definitely caused a stir, which if nothing else, provided an entertaining week of feed-reading. Absurd assertions will usually do that.
It’s so nice to see a post by you again! I really have enjoyed the articles you have written in the past.
I whole-heartedly agree with the sentiment that web designers should know how HTML/CSS works. Not that they can actually code complex designs – but at least have an understanding of how code (and the CMSes) they are designing for works. Or else their beautiful designs will not be well translated by the limitations that can be present with these tools.
Personally I think it’s easier to have a graphical mockup to code from, instead of coding first and designing secondary (unless it’s really flexible wireframing code). When I first learned to code I did all the CSS and HTML first and I look back and realize how hard it made things (and my crappy coding didn’t help!). Now I start with sketches, flesh it out in Photoshop and then break it all down to code.
I don’t think as a rule they always have to but they should be able to in a pinch. In the same vein of “know the rules before you break the rules”… I’ve got no issue with designers pushing the limits but they have to know what limits they are pushing. I’ve had enough designs dumped in my lap that suddenly become my nightmare to convert to HTML that I just don’t tolerate it anymore.
These days, IMHO, If you don’t know Intermediate-level HTML/CSS you’re a print designer, not a web designer.
Like Doug and Jason, and I sure many of us, I’ve experimented with many different approaches to web design. For myself, I find the page sketch to HTML/CSS the best approach because end product demonstrates how someone is going to actually ‘interact’ with the page. Static images don’t get at what will happen if for example User A select drop-down menu B then clicks Continue. Only after completely the HTML/CSS prototype do I begin to apply graphic elements to frame, highlight or emphasis content, navigation and functions.
For me, pencil and paper don’t cut it. I don’t use pencil and paper for word processing and see no reason to use it for digital design either.
One can say that the tools you use influence and limit your design. But I say that the tools you use are part of the design. For example, if I were to create an oil painting, I would use a pallet, brushes, and oils — and the influence of those tools would be expected in the final product. The visible brush strokes, the relief and texture of the painting, and translucent nature of the oils are part of the medium AND those features are expected. So, why look at digital creations any different?
I find the closer you get to the medium, the more honest the result. Keep in mind that we have an ever changing and functional medium that has no counterpart in the real world, so don’t hold it back by applying real-world tools. Look to coding as your brush, monitors as your canvas and functionality as your purpose.
Happy coding,
tedd
I think you make some great points and these posts (from you , Jeff Croft, and the 37Signal guys) just go to prove that this industry has many different ways to get to the end goal – a great, usable web site.
We have to be aware that we don’t become over-reliant on these tools and they end-up becoming barriers to that goal.
I really appreciate this perspective. I don’t think many people realize the influence that different processes and tools have on the outcomes and results of our designs and our thinking.
I have a couple examples of how software tools have affected designers’ thinking, and the outcomes of their work with particular tools.
In the design program of North Carolina State University, one of the professors noticed that students who learned typography in adobe illustrator had a more sensitive eye towards typography than the students who learned in quark or indesign. The professor attributed this distinction to the amount of control each software package allowed. The idea was that quark and indesign had an underlying grid that required more effort to deviate from, while illustrator was in the reverse situation, that is, the student would need to take steps to have an underlying grid applied to their work.
With this distinction, the students who used illustrator had to put far more effort into aligning, spacing, and creating overall structure and order, while the students using indesign didn’t have to pay as much attention because indesign did some of this work for them. Indesign did many of these things to a “good enough” degree, where the students only had to hand adjust the typographic items that were clearly offensive rather than having to pay as close attention to a greater number typographic factors. In a sense, illustrator was training the students to be more sensitive to important aspects of design.
Another related item that is I think is interesting is an argument Lev Manovich makes. His argument is that in a software package, the tools it provides, the processes it uses to accomplish tasks, and its embedded work flows results in a certain ideology underlying the software (the software authors may have been entirely unaware of the underlying idedology). This manifests in the idea that one tool is better than another tool for a certain outcome, (but every tool also has unintended consequences that are difficult to understand until a clear alternative has become popular).
So the example Manovich uses is, if you look at some of the architecture that was made over the last 20 years. Some of the more prominent practitioners adopted similar elements which had little historical precedence. Two examples Manovich uses are Zara Hadid and Frank Gehry, both use few right angles and lots of sweeping, rounded forms.
Manovich goes on to say that if you asked these architects why they created theses structures, the will frequently quote Derrida and other Post-modern, Deconstructionist theories. At the same time, software packages that were created for animation were adapted for architecture, and when combined with civil engineering structural simulations, architects were all of a sudden able to create structures and forms that previously would have been near impossible. Manovich doesn’t say that Deconstructionist theory had nothing to do with this, but rather it was the tools the architects used that were producing a certain kind of thought were some shapes, forms and spaces were privileged over others. It was difficult to reveal that software packages had a biased preference towards certain spaces that most considered appropriate and good, until something so different came along that questioned the ideology built into the software tools. In this case, it was that spaces that didn’t conform to a more rectilinear can be appropriate under certain conditions.
There are a few other examples, mostly pedagogical in how the tools we use affect our thinking (in what is considered good and bad design) and our processes for creating design. I hate to take up so much space here so I’ll stop now. I just think it is so important to understand how our tools affect our thinking, and the outcomes that they privilege so our design decisions aren’t based upon something arbitrary but rather on what we as designers believe is best for a particular audience and context relationship.
Spot on. Good to hear from you again.
Good catch, there. Conversely, you might find that you don’t actually skip HTML/CSS, either. Even if your early Photoshop comps forced you into some CSS invention, they still benefitted from the CSS foresight that you had accrued to that point.
The real question is, are you still designing to those CSS edge cases, or have you decided to benefit from the very standards and practices that you helped create? If you never code the same way twice, then by all means continue to claim that you design straight in Photoshop. Otherwise, you must admit to keeping a mental-model of your HTML/CSS even as you work in Photoshop. The only difference between your mental-model and 37signals’ HTML prototype is that you can’t attach yours to Basecamp.
Even considering the CSS constraints that your early PSD’s exposed, I would venture that HTML/CSS exposes far more constraints in Photoshop. Ever try to build a liquid background with hover states and export to transparent PNG’s all in one go?
It has amazed me to see so many CSS luminaries deny the very pedestals on which they stand, pedestals that they helped raise. There is no shame in the material influence on art. Technology has always shaped the path of art. From lapis lazuli to acrylic to cement, each material invention was the benefactor of an artistic movement. Why does it seem so difficult to acknowledge that HTML/CSS skills are the underpinning of good web design? Just baffling.
Brad, either you’re just trolling, or you completely and utterly missed the point. I’ll give you benefit of the doubt, in case it’s the latter…
No one is saying we skip HTML/CSS. No one is denying that HTML/CSS skills and understanding are important in web design. And no one said we completely omit consideration of the medium in which we work.
*My* design process is more open and less limited when I don’t start with HTML/CSS. Get it?
Totally agree with you. Coding means established rules. Design means trying to create new rules.
Got your point, but I’m afraid I wasn’t as clear with mine. I’d agree that coding is confining, but I’d add that Photoshop, Fireworks, and the current state of web design tools in general is confining as well.
Like I said, I think it’s much easier to come up with a coding scenario that isn’t easily depicted by a photoshop doc than a psd that can’t make its way into HTML/CSS in one form or another.
So, if you are working in the space between liquid CSS, AJAX and Photoshop. There really isn’t yet a unifying tool (or set of tools) on which you can lean. Fireworks with Photoshop comes close, but even then some interactions will spill out into new docs.
You were very perceptive in calling out 37signals’ paper sketches, but I think you are making the same mistake by not allowing for the effort that standards designers bring to the table to make Photoshop a serviceable application.
The sad fact is that none of these tools allow for complete freedom for creativity. It is still largely the designer’s responsibility to keep the vision across the codes and the applications. That is the real starting point and often also the endpoint. Contrast that with print design, where a design can be trailed from concept to CMYK within a single suite.
@bradmar – Point taken, and well-said too. Thanks for the followup.
As Nicholas said, I believe each one of us uses the tools which we feel more comfortable using. Of course each tool influences and probably limits our work, but that also leads to variety.