Rant to follow:
So I have done a fair share of PSD to HTML, PSD to WordPress theme, PSD to application web GUI, etc. rewrites. I generally have no problem with the concept of this, and got quite good at this. However, there are some real pet peeves that keep coming up in this workflow, that are really driving me crazy. If you are a designer working with a developer, and you happen to read this, at least please consider it the next time you produce a PSD:
First, PSD's that assume text length. For example, if you have three call-out boxes with a title and some text to follow, don't assume that the title will always be one line and the text will always be the same length. Instead, figure out what this will all look like when you do have very uneven amounts of text. Do we center it vertically? Do we abbreviate it?
Second, PSD's that don't assume a responsive design. Sure, working directly in the medium (HTML/CSS) would solve this, but you can still provide some direction here. Tell me how the columns should be laid out. Which parts of the site should expand/collapse with size, which parts can be hidden, etc.
Third, and this goes without saying, but clean up the PSD layer names and groupings. Layer 1, Layer 2, etc. is not a great convention for this.
Fourth, show me the unusual cases. I know the clients always want to focus on the prominent pages, like the home page, the product listing, etc. Those are important, give me those. But also give me what a form submission error looks like. Or what a 404 page looks like. Or an empty shopping cart. Or pagination. Or a table that's wider than the viewport would normally allow.
Fifth, consistency. It sucks for the developer, and I'd argue it sucks for the user, to have every page use a slightly different set of CSS rules for headers, paragraphs, lists, etc. Best case scenario here is to give me a style guide I can trust. I know it's two different documents you now need to maintain, but honestly this is the biggest help you can give me.
Sixth, show or describe to me the interactions and workflows. A simple shopping cart can become a giant minefield of interpretations of what the design is supposed to convey.
Seventh, and this is a bit meta, but don't walk away from the design before a single line of HTML/CSS is written. This is bad because there will be questions about interactions, etc. If first I have to email your boss's boss to try to see I can ask you a simple question, the process is broken and I will not recommend working with you again.
Eighth, if you do promise to deliver sample HTML/CSS, for the love of good, do this well. I have recently had the misfortune of having HTML/CSS/JavaScript delivered to me for a large site redesign by a big name web design agency. I was very excited about this, especially since these guys said they would use Bootstrap as the foundation for this so that we would have all the benefits of that framework built right in. I got the files, opened them and OMG. It did include Bootstrap, but in name only. After that declaration, it instead included a completely custom column system that was just slightly incompatible in sizes with Bootstrap's. It also used none of the same class names even where it made sense, etc. Needless to say, I had to re-write all of their CSS from scratch, and re-adjust lots of the Bootstrap variables to accommodate their column system.
Great designers are worth their weight in gold. The above highlights that the waterfall process of design -> develop does not work. Instead it should be design -> develop/design/develop. If you cannot step outside of Photoshop that's fine, but if you want to be efficient, you must know the final medium, which is the web.