Be the developer! Or at least that's what I do.

You know your design more than the developer, along with how your design should reflect responsively. A good designer, in my honest opinion, should implement their own design.

Learn to code, it ain't that hard :-)

For web: I build everything myself as HTML/CSS/JS with images I've created. If code that's beyond me is required, that's done as the very last stage.

For apps: I provide folders with correctly named, correctly sized final image assets. If changes need to be made (for better performance or implementation), then I make them and re-export everything using a slice sheet Photoshop document I create when doing the initial export. I also provide specs for text and code-draw elements as a text file. I never, ever, under any circumstance give a developer a PSD.

Ideally, just build out the HTML/CSS myself. But, otherwise PSD with Annotations in Photoshop or PNG/JPG Mock with assets pre-sliced. I also try to build hex-codes and other tech details into a master template design or a style guide. If I need to give notes, Ill usually add in e-mail or send a Drive doc.

I find PDFs to be clunky for working with a developer. Client presentations or non-tech its usually fine but the ratio to screen tends to be not smooth enough. I know, it can support layers and such but generally still doesn't feel good for me.

For mobile apps, I slice and properly name all assets into folders named for each screen. Most of the time I sit next to the developer and give them colors, fonts, positioning. Otherwise I make a blueprinted spec with everything called out (pixel spacing, colors, fonts, etc). In the past we created an indesign file with a list of all the colors and fonts called out, then a comp of each screen with all the pixel spacing. This became wildly out of date too fast and the time it took to maintain it, made it not worth it.

For mobile designs, I give preview PNGs (for composition, dimensions, etc.) and exported resources (PNGs). Developers are usually nearby, so I can explain interactive actions in person.

For the web, I give HTML and CSS.

Another vote for building it yourself. This is what I do with web stuff.

For mobile, I build prototypes and hand those to the developer, along with assets. I built my own tool for creating prototypes: http://www.flinto.com, contact me if you want an invite.

For mobile, sitting together with your developer is the best you can do. It's not only that both of you get to learn the other's workflow but you're also woking faster (solving problems together, not slicing stuff that is going to get hardcoded anyways, no back and forth e-mailing about how a certain feature should be implemented) while building a higher quality product. I always try to slice the assets in advance and give them self-explanatory names (Area-ElementInCamelCase-State@2x.png; for example: Profile-FollowButton-Tap@2x.png) in case the dev is on his own. When working in a team that I trust I also send the dev my properly annotated PSD with LayerComps for each screen because for many things like colour or size it's just faster and easier picking them out of the PSD.

I don't do much pure dev these days but if I do, I insist on:

• Illustrator files, not Photoshop (useless for retina assets) - and absolutely no PDFs
• No bloody decimal pixel dimensions
• RGB document color settings: it's incredible how often I'm given CMYK stuff

If we're talking about a website / webapp:

1 I build the HTML / CSS myself and hand it over to the development team to integrate it and then go over it again with them to fix anything that's not right. Rinse and repeat.

2 If I fully trust the quality of the work from the frontend folks: just structured mockups of the key views + an extensive UI Stylesheet (form elements, buttons, notifications, headings and paragraphs, icons, color palette, explaining the grid and the spacing / padding rules) + constant communication & feedback on everything they do. (this doesn't really work for responsive websites but hey... that's what #1 is for)

I could just code all my designs but if I'm working with great developers I'd rather leave that part to them and spend my extra-time solving more high-level design issues.

For mobile design, I tend to build prototypes or hand over some rough front-end code. Otherwise, we'll hand over some wireframes, and after the developer does a first pass, we'll go through and "pixel-nudge" their work, sitting side-by-side.

Mobile's gonna get to be like web, eventually: in order to be a competent designer, you'll need to know a bit of front-end coding to do your job right. If you're an iOS designer, I'd recommend you learn to use UIKit and Quartz to draw your designs in code. (Paintcode is a great resource for this.)