Occasionally a potential client will ask us to give them Photoshop comps as the final deliverable, to be coded either by an internal implementation team or a technical partner. We don’t do that. Here’s why.
A website is code. Sure, it’s images and copy, too, and those images and copy are placed in the code only after careful consideration of the client’s strategy for the site. But a website is code. Even if you just saved all the comps as JPGs and made image maps out of them (funny story there, but later), you still need code to make those image maps work.
Our design process is not short and it is not simple. We spend significant time and effort doing research and visual design before we even get to the code. That process results in a set of sample pages that demonstrate all the pieces of the visual system for the new design. Depending on the project, we’ll either create all of those pages in Photoshop or do a few in Photoshop and build out the rest in code. But *all* the comps are delivered as code.
That code is two things:
1. It is the final culmination and proof of all the work that we’ve done with and on behalf of the client.
2. It is the basis of a design system that will be used by the implementation team to build the rest of of the site.
When we take a website’s design all the way through code, it means that we have spent the time to test the solutions proposed by our strategy, IA, and visual design work. We have made some potentially difficult decisions about whether a particular aspect illustrated in the PSD can actually be implemented in a way that benefits the site, not just code something because it’s in the PSDs.
Finally, it ensures that the code that forms the basis of the entire design system and website is clean, conformant, and tested. We don’t just slice up our PSDs and export them through ImageReady. We code our final pages by hand. What goes in the code is only what should be in the code.
As Mike is fond of saying, “A PSD is a painting of a website.” We don’t spend weeks or months understanding a client’s complex needs and issues to make them paintings. We spend all that time to solve problems, and paintings don’t solve problems. They may illustrate potential solutions, but there’s a lot of room left for interpretation, and that poor interpretation of a solution is often what has led the client to our office in the first place. So we don’t do it.
There’s been some confusion about whether the client has the right to the PSDs or if we’re just being jerks and hiding them. I answered many of these questions in the comments, but for clarification:
The client is welcome to have the PSDs at the end of the project. But those PSDs are an artifact of the design process, and very likely do not reflect all the final decisions made in the coding process. The code is the deliverable, the PSDs are not.
Mule creates delightful interfaces, strong identities, and clear voices for useful systems and nice people.
Also, We are funnier than all other designers.
Five stories, five minutes. Your commute-sized way to catch up on the news.