A few weeks ago, Jason Fried of 37signals caused a mild stink by blogging about why his company doesn’t comp their designs in Photoshop:

…we’ve found that going straight into HTML/CSS affords us the best iterative and creative experience. HTML/CSS is real in a way Photoshop will never be.

Be sure to skim through the comments.

One thing I think web developers tend to miss when reading Signal vs. Noise is that 37signals isn’t a web development company, they are a software company. The majority of web developers build custom websites/web applications for clients. 37signals (primarily) makes hosted software based on what they think is useful, intuitive, and powerful. They make the rules, they decide how it works, they get to make it look the way they want it to look. As far as the design of their product goes, they are essentially their own client. Yes, they need to deliver a product that makes their user base happy, but those details are largely usability related, not texture, drop-shadow, serif, help me sell my sunglasses to 20-something surfers related.

I don’t think for a minute that 37signals should cater their blog to web developers, nor do I think they should attempt to clarify this difference in their blog posts (not when posts like the above play off this confusion and increase ad revenue). There is an endless universe of web developer resources online. They are a wholly unique company. If any one company should have a blog that celebrates what makes them unique, it should be them.

I think it’s more important for web developers to remember what they are reading. And for those web developers having trouble remembering why it is they do what they do, allow me to offer my list of why we scrutinize every detail of every project in Photoshop before going to build:

1. Delivering a product that isn’t anything close to what the client envisioned is a product you have to build again. Building a project more than once, but getting paid only once is bad business. In our experience, laying out exactly what the end result will look like weeds out all the discrepancies about how information will be displayed in every possible state. Doing this after the fact can often require significant changes to back-end logic. Changing the format of a date in a smart layer in Photoshop is infinitely quicker than changing database queries, CSS, and PHP/Ruby/Python/C# code, and then changing it back when the client decides they liked it the old way better.
2. Not every client has contracted a website before. Many of them are clueless as to what is even possible on the web, or possible within their budget. “I wanted ITC Berkley Oldstyle for the body type, just like our brochure!” Again, weeding all these limitations out in the design phase is much more efficient that recoding a framework after the fact.
3. The PSD files used to build the site comps can be directly exported for the web to use in the style sheets and as embedded content in the actual site. All of the graphic elements have to be built anyway, and it is much easier to build them in context with each other.
4. Fleshing out various states of a particular element is often critical as well. Not every page we build is static. In fact, no pages we build are ever static. At the very least, each anchor element on an html page will have a hover state. Popup menus, tool-tips, context menus, zooming image widgets, all of these things need to look like something, and their graphic elements need to be created somewhere.
5. Most people like to see site elements a few different ways before deciding on what they want to go with. Often times it’s helpful to see them side by side during this process. Coding three versions of a page and displaying them side by side is not faster than pasting and dragging around a few layers in Photoshop.
6. Starting build before final designs have been approved, and more importantly—signed off on, has cost us more money than I would probably be allowed to say here. It is mostly because of this that I can say without a doubt, not presenting your client with a comprehensive visual representation of what their finished site will look like before build begins could put you out of business.

The look and feel of products like Basecamp, Highrise, and Backpack can easily be achieved in strait XHTML and CSS. I can see how jumping right into development builds could be a more efficient way to design those types of projects, especially when you are building on top of a sweet MVC framework like RoR. In the real, non-in-house designer world, however, clients rarely want their websites to look like computer software. Do you think Cuban Council designed Suicide Girls without Photoshop?

Further, you don’t always have control over what platform you are designing for, or what kind of markup you are being handed. Not every platform is as agile as RoR, nor are you always designing a brand new site, its logic or markup structure.

In the past two years, 2 of the 40 projects I worked on actually warranted a simplistic, utilitarian design. Even in these cases, compositions were created in Photoshop or Fireworks first. The simple fact is our clients hire us to design them something, and clients like to change their minds about what information they want displayed where.

I love reading Signal vs. Noise, but it is plainly obvious that 37signals is anything but a web design company.