I love that a tool like Zeplin exists at all, and focuses on the handoff, because I think that’s often the weak link in the design process and nearly as great a threat to successful design outcomes as designing the wrong thing. So any approach to design that focuses on navigating delivery and guiding a design to fruition is better than just calling it “finished” and hoping for the best. So much more is left to chance that way.
In the past, I’ve also tried to connect more dots by making the deliverable behave more like the product. In other words, an interaction design spec could just as easily be interactive. It doesn’t have to be exhaustive and bulletproof for all edge cases but it should cover the principal and key paths, and the system-response flow should be self evident through direct interaction. This puts a lot less pressure on developers to parse and understand documentation describing the intended behavior of the system.
Show vs tell. Easy to say, of course, and plenty of great tools like proto.io or sketch or balsamiq or incision or axure are hopefully making it easier to do.
If you happen to design in production code - and developers are in the design process loop from the outset and thus understand how you pull together and reuse patterns - you can also develop a kind of shorthand notation that demonstrates how you’ve scaffolded the finished work together from the language they’re hopefully already using. This is where the line between design and production and deployment blurs more, and frankly I think that’s a good tension to introduce in teams.
(And when a deliverable is based on a new design framework altogether? That’s another animal to discuss and probably worth a separate conversation thread!)