[IgorPartola]

To pile onto wonderyak's point, I am a developer, not a designer. I wish I was also a designer, but due to where my talents and experience lies, I cannot do both well at this point. The problem is that I cannot tell what is and what is not important in a design that is handed to me. I have had conversations with designers where I inadvertently change a margin on a callout box by +/- 10% and the designer notices and explains that they arrived at the exact margin by a long research process, and by the way it matches all other places where the margin is exactly 40 pixels and not 36, etc. There are changes that are not consequential and there are changes that completely undermine the message the designer was trying to send. This is not an ego trip. This is a professional telling me that they've thought through the problem and I trust they know much more about the problem domain than I do.

Ideally, I try not to change the design if possible. However, unless the designer is very good, it does require lots of tweaking here and there, which introduces delays and compromises the vision for the finished product. If a designer has long since walked away, it can become a huge problem.

[grey-area]

As a designer and a developer (I often do both), I think I see where you're coming from, however I feel this is more a sign of a breakdown in the relationship between the developer and designer than a shortcoming of the tools. Design isn't so scary - I think a lot more developers should try to pick up a little, just as designers should know at least a little about the final medium for their work, and in an ideal workplace there should be at least a handover with plenty of chance for feedback on things like text styles, not just throwing something (PSDs in this case) over the wall from designer to developer.

I would never accept a photoshop comp as a developer or send one as a designer and expect it to be reproduced exactly, because it's in the wrong medium, and it's a terrible way to specify things like text sizes or column widths except as a general indication. There has to be some give and take (and a lot of feedback) in a process going from something static and done without grids like a sketch (e.g. a psd or pencil sketch) to a final website, so what you describe in your feedback from the designer is a normal process I think and to be welcomed, it's inevitable in the translation to HTML. The design will change as it has content added and goes into templates, adaptations will have to be made, and the design must be flexible enough to deal with that, and your designer should be around to help with it - if they're not they're not doing their job properly.

I guess what I'm trying to say is that dealing with change is part of the job in design, and your designer should gracefully do so, in which case it is no problem if they gave you a vague psd - it should be vague at the early stage before implementation, because there will be changes, and additionally, html is just not a medium which allows us to specify layouts which are exactly the same in all conditions - browsers, text sizes, fonts, scripts, proxy servers mangling images, user stylesheets all affect layouts, so you have to accept that not all users will see content at exactly the same sizes or with the same fonts or even the images as you intended them (if they're on a mobile network, a proxy might have downsampled the images).

[IgorPartola]

So this works really well when you are working with the designer. When I can walk into your office and say "hey, can you pull up the dev site and take a look at page X? I think we need to figure out a better way to display this" I am very happy. Even mediocre designers can deal well with this modus operandi and produce much better than mediocre results.

Where we run into a problem is when a client hires a design firm, works with them for months on a new site or application look and feel, gets invested in it, pays the designer and maybe even starts development with a few days' overlap with the dev shop. Another example is when you deal with extremely low budget jobs (less than $1k), where you are simply trying to minimize hours spent on a project. I have done WordPress themes off good, clean PSD's only in less than 8 hours. I have also spent close to 80 hours on some where the PSD's were super detailed, but lacked any kind of direction. When the designer or the developer is not in-house, communication is key, but is often a place where costs are cut.

[grey-area]

I truly believe both design and development must be ongoing and collaborative processes, and the problems you've identified above are all down to trying to divide work at points where it cannot usefully be divided - the first scenario you mentioned is the only way to produce good design IMHO - as a collaboration with the client and any other parties like developers.

[wonderyak]

I agree with everything you're stating here, I just wish it was that easy in practice.

Some of the problems with deliverables is managing client expectations, they expect or have gotten used to seeing output of a PSD that counts as 'what their site will look like'. The creation of a PSD as a deliverable for the 'final design' is boilerplate for every agency I've ever worked with.

Responsive design has finally started nailing the coffin though; it becomes too cumbersome for designers to create renderings of different viewports, let alone understand the intricacies of how media queries work or how assets are delivered to different devices.

There has been a lot of creative thinking about deliverables (Style Tiles, Atomic Design) which is helping us get over the hump.

I would hazard a guess that most of the sites in the SMB space are either WordPress templates or custom designs that were then handed off to a service or an outside developer to make into functional websites. Sometimes, the developer doesn't get to see anything until the client has signed off on the design. I see this happening with large companies which do multiple millions of dollars a year in agency work.