I have seen a few good articles, and tools like Zeplin.io on this. Does any know of any video training that walks through an explanation of exactly how this done?
I did use Zeplin in a recent project, it seemed to work well, but I would like to become even more familiar with this.
Any suggestions?
@tara_lee_york
this tool was on our radar for a while.
I really like it but I never tried it fro a real product design process.
Since our process is handled with InVision, we are pretty happy with the built-in developer tool.
I’d like to know why you choose it?
I chose it because it integrated with Sketch - which is my go to design tool. I was unaware that Invision had spec tools like Zeplin.
I had been using Marvel mostly for prototypes, but I interested in Invision insight tool. I think I’m going to give it a try. https://www.invisionapp.com/blog/insight-ui-designers-developers-collaboration/
cool!
We chose InVision only because of sketch (we use it as pixel perfect design tool)
Again I didn’t work on any real project with Zeplin so I can not compare the tools.
The InVision feature is in beta version, so far works fine and we are massively using it.
Let me know about your experience with it 
will do
Excellent question to raise.
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!)