Wondering says:

so, wait... is that to say that the client will never be given the PSDs?

August 26, 2010 1:34 PM

David McCreath says:

@Wondering

The PSDs are an artifact of the design process that very well may show differences from the final coded pages. At the end of the project, if the client wants those artifacts, sure. They can have them. But they're really not very useful.

When we bundle up the code for delivery, we'll also include any production files that might be necessary in extending the design system (image button templates, image background templates, etc.) which are definitely more helpful.

But the PSDs are not the deliverable.

August 26, 2010 1:43 PM

Victor Zambrano says:

I understand your point, but I think the analogy is somehow biasing.

As a former architect (and current web designer), I know buildings are brick and mortar, but I'm still expected to deliver plans, sections and all kinds of blueprints of my designs. Which I will extensively specify and annotate, under strict standardised codes, for any (preferably a good) contractor to build.

I just imagine if I could build all my (building) designs it would be brilliant, but, unfortunately, I cannot all the time. And if I had a construction branch within my company, I could say no to all the clients that don't want me to build my designs, but that would surely be little business remaining (ask any architect).

So I guess what I'm interpreting, besides the cute analogy, is that you prefer not to give your clients extensively specified and annotated plans of your websites in order to maintain quality standards of work, not that it is not possible to maintain high quality standards of work if you don't build the website yourself.

(I recognise my previous phrase tends to impossibility almost all the time. I recognise the lack of standard code of specification might be a problem when communicating design to developers, but not one that can't be circumvented and overcome. I also see that usually clients will select an external developer for their low prices, not realising the value of what solid brilliant coding means for a web project. I also acknowledge that the lack of strict legal standards of construction, supervision and approval of web projects, unlike architecture, makes it very difficult to prove something is built properly and solidly. So there you have it, I do know it is bloody difficult.)

August 26, 2010 2:46 PM

David McCreath says:

Actually, Victor, we rarely build out the entire site. The sample pages that we code define the system for building the site in HTML, CSS, and JavaScript. We provide documentation along with the code, in addition to all the other work that we've done.

In keeping with your architectural analogy, the code that we deliver, combined with the information architecture and strategy documentation make up the blueprints. The PSDs are the scale models.

We'll talk more about our documentation in future posts.

August 26, 2010 2:51 PM

Jay says:

I would think that in many situations, the way that the design is to integrate with the CMS needs to be heavily considered while constructing the code. If you're only making sample pages you seemingly would not have this insight.

What if you're working with a web application developer, as opposed to a web site. The relationship between your code and the developers code is even more intrinsically related.

You seem to be holding yourself back with such a limitation. Or is it that you're just not interested in supplying for these kind of relationships?

August 26, 2010 3:50 PM

David McCreath says:

There are a few answers to that, Jay. First and foremost, we are as CMS agnostic as possible in our code. It might be helpful to know what CMS the site is going to be built in, but the constraints of the CMS should be secondary to the design of the site.

That said, part of our discovery process is a thorough technical review to make sure we know what the constraints are before we even get into the IA. If the implementation team is already part of the project (whether internal or a third party), then we talk with them and find out if there are any special requirements or limitations for the CMS. In almost all cases there are not.

Two of our recent projects had design, development, and implementation overlapping, and we were working from the same source repository as the implementation team (Git in one case, Subversion in another). Each project used a different CMS and in each case our technical partners provided valuable feedback about the code as they built the site, but for the most part it was about CSS or JavaScript bugs (both sites required high-level support for IE6), not about CMS issues.

There are also cases where for some reason the implementation team has not been selected by the client when we start our part of the project. In those cases, we ask the client to put us in contact with them as soon as they are selected so that there are no surprises for any of the three partners.

August 26, 2010 4:46 PM

Dustin Senos says:

You have clients sign off on the mockups before you implement them correct? If not, it feels like you're jumping through hoops prematurely and creating work for yourselves.

August 27, 2010 2:29 PM

Darcy says:

Some good points here though I see nothing wrong with giving the client and/or developer early access to a design to get feedback. Especially when coupled with a tool like Pencil to create quick and dirty (yet somewhat polished) interactive prototypes. The time it takes to put that kind of prototype together vs. a working html/css/js doc is significant. We've gotten valuable feedback (especially with applications) working this way that we wouldn't of if we hadn't involved the client at this stage.

August 27, 2010 2:33 PM

Joe Barstow says:

before the chicken or egg there were about 100 paintings of a chicken and they were balled up into little egg shapes and tossed in the waste basket waiting to be picked up and given purpose to their lives again

August 27, 2010 2:39 PM

Jera Batten says:

Do you have any thoughts or advice for freelancers who create PSD's at the client's request, at the client's direction that those PSD's will be passed along to a developer? What is the best way to represent these files in one's portfolio and to properly give credit?

August 27, 2010 11:15 PM

Marwan Salfiti says:

"What goes in the code is only what should be in the code." Right on... Too often sites and code become bloated because a developer isn't in "touch" with the intention of a site's usability.

I know I will catch heat for this, but many times some of the best developers can write code poetry, yet can't think like a user if their life depended on it. Hence, those decisions cannot be left up to a dev or dev team alone.

I think what David is getting at is that the PSDs are a piece of the puzzle, but the code and functionality is the "styleguide" and end product. Design studios don't want to be viewed as production houses, rather as solution providers.

August 28, 2010 10:20 AM

visitor says:

Let me see if I understand, you don't provide the latest PSD version when you deliver the product? What if my slogan is part of an image and I want to change a word, let's say 2 years from now? Should I pay you extra for this 4 minutes work because I don't have the source PSD?

August 30, 2010 6:12 AM

Judith says:

I've been on the client side at Mule (and elsewhere!) and I will say that it is a huge advantage to have the deliverables in code form vs. PSDs. I've spent too much time watching developers do all sorts of contortions to figure out a particularly tricky CSS implementation of what they thought a designer wanted, only to find out it doesn't work in all browsers or breaks something else or some other nonsense I don't have time to figure out.

As David said above, of course they'll bundle up the PSDs so you don't have to pay extra for a change to your image-based slogan, but that's totally not the point. The point is that your site has clean, compliant, well-documented code that is exactly what was agreed-upon, designed, and paid for - not some second-generation interpretation that your developers, who likely weren't in the room for the endless rounds of discussions between the business folks and the design team, are guessing is what you meant.

August 30, 2010 10:08 AM

David McCreath says:

Jera -

If your part of the work is the visual comp, and not the code, then the comp is what goes in your portfolio. The tricky part of that (and this has been discussed widely on the Internet) is that visual comps suck at illustrating interaction. The best you can really do to show multiple states of a single page or screen is show multiple comps, or maybe some kind of clickable comp/image swap thing. But that's not the code.

It really depends on what you're trying to sell as the freelancer. If you want more work making Photoshop comps for a client's team to implement that, then the most important thing to demonstrate in your portfolio is how your comp met the client's needs. Make it clear that you did not code the resulting site, but talk about the process that got you from the initial conversations to the thing you delivered.

August 30, 2010 12:24 PM

David McCreath says:

"visitor" -

As I said above, production-level files are provided (logos, backgrounds, asset templates) because those are useful and up-to-date, but the comps themselves very often do not reflect some important final design decisions made in the coding process.

At Mule, coding the sample pages is the final step in the design process, the proof of the work we've done with the client, and the first step in the development process. The full-page Photoshop files are leftovers. Of course the client is welcome to have them. Not all clients take them or need them.

August 30, 2010 12:29 PM

Mark Duffy says:

i see nothing wrong giving a PSD to a third party to code. A good graphics/web designer usually never has to know more than states of a given element and not how the css or javascript makes it happen. If the developer has limitations with browsers or javascript he will be the one that finds it. Not the designer. I've never came across a web designer that felt the need to zip up code along with PSDs. This sounds more like your either nervous to give up your baby or you'd rather see a job through to the end. If the latter, have you ever received a PSD to code? What issues have you had when this happens?

August 31, 2010 9:36 AM

Aaron Burrows says:

Great article. I like the holistic approach to web design. The code is just as much a part of the design as the imagery and layout. Many of my design decisions are made once I'm in code, and by the time I'm finished, there is no PSD comp that exactly matches the final design. I find myself spending more and more time creating (or at least finishing) designs in the browser rather than Photoshop, though image comps are an indispensable part of the process.

Also, people need to lighten up and read the full article. Some are getting offended that you would withhold files and resources from a client, when in fact you said that all the files are made available.

August 31, 2010 9:50 AM

David McCreath says:

Mark -

Of course there are third parties that can create code to the standards that we would expect; that's completely beside the point.

The entire point of the article is that at Mule, the code is the final step of the design process. Design does not stop when the client signs off on the PSDs. Design stops when we've coded enough sample pages to know that we have a solid system and that the implementation team can focus on the middleware and back end, not puzzling out our design decisions.

As to this: If the developer has limitations with browsers or javascript he will be the one that finds it. Not the designer.

The very reason that we have our process is so that this kind of thing happens in our shop and minimizes the impact on the outside implementation team.

And no, we don't code other PSDs from other designers as part of our process. There are businesses out there set up just to do that. We're not one of them.

August 31, 2010 10:07 AM

Stefan says:

oh my god I sooo understand what you are talking about! i don't mean about the psd as deliverable but the part where "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". i am a web developer. i am not a web designer. i work with web designers that don't think their designs in "code" but, as "paintings" (as they have only very basic knowledge of HTML, CSS and JavaScript). and, therefore, implementing their designs is sometimes a bit difficult not to mention that sometimes the designs are not very well suited to web.

August 31, 2010 11:43 AM

Ricardo Francés says:

Remember Derek Zoolander? When presented with the architectural model by Mobutu... How did he react?

Clearly, we could illustrate the client. They already know the legend "Results may vary. For simulation purposes only." because manufacturers have already taken that into consideration for their products, shouldn't we be doing the same?

August 31, 2010 1:10 PM

Leafkit says:

And that's one reason why I'm more likely to get a client than you. Because the client thinks they're getting more when I hand over the PSD along with the style guide.

August 31, 2010 11:19 PM

David McCreath says:

Hi, Leafkit. Let's clarify a couple of things.

It appears that you might be assuming that we don't deliver any sort of documentation with our work. This post is not about our complete set of deliverables, but to be clear, we do provide documentation. It covers everything we've done with the client: discovery, strategy, IA, visual design, and code. It talks about how to use the system described by the code to build out the entire site.

It also appears that you feel you must trick your clients into signing with you by convincing them that you give them something more by giving them the PSDs, which (to reiterate, again) we consider an artifact of the design process. Is that the case? Because I'm not clear. Do you deliver code with your PSDs and styleguide?

September 1, 2010 7:41 AM

chad says:

awesome explanation. awesome reasons.

September 1, 2010 2:13 PM

Timur says:

Sounds good but not for my clients. For them all this explanation will be simple bullshit. I even will not try to tell them that they will not get psd file.

September 1, 2010 3:02 PM

Leafkit says:

First of all, I never said you don't deliver any sort of documentation with your work, I'm sorry if it appeared that way. Secondly, I can tell you that I do not feel I must trick my clients into signing with me, the PSD isn't the deciding factor, all of the deliverables are the deciding factors, code, style-guide, PSD and customer service. Like Timur said, try explaining all this to the client that does want the PSD and drops you because you won't cough up. Will you not take on that kind of clientele?

September 1, 2010 8:42 PM

Aaron Burrows says:

@Timur, @Leafkit

I think you people didn't even read the article. Mule delivers everything the client needs to own and maintain their site. Leafkit, you said "try explaining all this to the client that does want the PSD and drops you because you won't cough up." yet you must not have read the original post because it never says they "won't cough up" the PSD files.

In fact, if you read the comments (which I assume you are, since you're leaving comments yourself), they clarify the point further by saying:

"The PSDs are an artifact of the design process that very well may show differences from the final coded pages. At the end of the project, if the client wants those artifacts, sure. They can have them. But they're really not very useful.

"When we bundle up the code for delivery, we'll also include any production files that might be necessary in extending the design system (image button templates, image background templates, etc.) which are definitely more helpful.

"But the PSDs are not the deliverable."

It's clear to me that they don't hold back. They made it clear that all necessary image resources are delivered along with code, style guides, etc., but PSD page comps are not delivered (unless asked for) because they are not hugely integral to the design process.

I can't stand it when people pop off with their comments but don't bother to pay attention to the thing they're commenting on.

Also, it's the acme of arrogance to say "And that's one reason why I'm more likely to get a client than you." You don't have any numbers to verify this, to prove somehow that Mule loses clients because they don't give up PSD's. And the Mule home page is quite a bit more than a "coming soon" page. Just Saying.

September 2, 2010 8:14 AM

David McCreath says:

Leafkit -

As to whether or not a client would walk away because they want only the PSDs and not the code: It's part of our statement of work that our job is not done until we have coded the sample pages that make up the system. I can't think of a time in the last five years that a client has not understood the value in having us create the code for the design system, since we are ones creating the system in the first place.

As has been reiterated more than few times in the comments, if the client wants PSDs at the end of project, yes. But we don't update them after we start code, and some may be more different than others, so they are usually not very helpful, especially as a set.

Think of it as an opportunity for client education, and helping them understand the difference between the painting of a thing and the thing.

September 2, 2010 9:20 AM

Silviu says:

I. A freelancer. I have a lot of clients but 90% ask for psd at the end of the project.
But kf they need changes will came back to me. Always does

September 2, 2010 2:14 PM

Ronan Murk says:

OK, so this article does begin with explicitly stating "we don't do that...". On that I would like to comment:

Surely if someone wants PSDs, or FLAs, or AI files, or absolutely anything else under the sun, and they are willing to pay for your expertise, the time spent on the research and the build, the effort gone into the strategy etc ... why would you refuse? It's only work, and it's only being swapped for money (it is a given that you will not accept work if the pay is too low).

Is it an ego thing? I agree with all your points about the build process, but who cares if the client wants PSDs, charge them for it from the start and move on. No?

September 9, 2010 6:25 AM

David McCreath says:

Hi, Ronan -

If you read the first paragraph in its entirety, it says (with some added emphasis):

"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."

If you haven't read the twenty-eight comments previous to yours, I encourage you to. I said repeatedly in the comments that if a client wants those PSDs, they can have them. But they rarely represent all the sample pages that make up the system, they frequently show differences from the final coded pages because we figure out that something experimental in a comp isn't working in code, and because they are a leftover. They are not a product. The code is the product.

Get it?

September 9, 2010 7:25 AM

José Pacheco says:

For one side i fully agree. the industry in general gives the final products to the user/client...

dont give them the machines to make the final piece. its a huge presumption with an huge interpretation but seems fair.

September 17, 2010 7:18 AM

Anonymous says:

I did NOT understand the point of your article. You must make your ides clearer and simpler. It was the comments of the visitors that made ting clearer.

September 22, 2010 7:23 AM

Tim Zheng says:

This is stupid. Just another excuse to squeeze more money out of your clients. Your PSD is your final product, just charge more upfront.

September 23, 2010 8:32 AM

Jay says:

I think of it as cars. You design a car, build it, then sell it. You don't give the blueprint to the client. They are your working files.

September 23, 2010 6:52 PM

Lou Sparx says:

You can avoid problems, and misleading by clearly stating up front.. exactly what the client will be receiving. It's then the clients choice whether they work with you or not.

September 24, 2010 4:56 AM

Arthur says:

@Tim Zheng PSD as final product? Wow. Goodluck to my client making a website out of PSD's

September 26, 2010 7:55 PM

Gemma says:

There seems to be a lot of ignorance and arrogance in the comments about the article. People, READ the article, and then REREAD it until you understand. The point of the article is very easy to understand. Stop giving the author a hard time.

October 5, 2010 11:23 AM

Tracy_T says:

None of my clients have ever asked for a PSD. Some of them don't even know what it is - or, care - for that matter. They just want to know that the site looks good, and functions well when done. They don't care how I got there.

March 30, 2011 10:41 PM