As I mentioned in my previous post, if you set up your interaction storyboards correctly, it's a very short road from your static version to an animated one.
Typically my static work goes into some sort of an interaction script format that provides annotation and detail to the stories I'm trying to tell with those graphics. Then it's pretty simple to figure out what I need to animate. If I'm scenario planning, I tend to winnow down to one or two options before I move from static to animated content - saves time and makes decisions simpler with far less changeback as you prevent decision overwhelm. Good way to stay out of that lizard brain while keeping interest high in your feature stories.
My current workflow is using Illustrator to set up my wireframes, mockups and static interaction storyboards and then transferring into Flash or Fireworks to add animation. I may give Keynote a try one of these days as I see a lot of folks finding that an easy transition for presenting and design research. You can see @lukew's interesting write up about how that is becoming his favorite workflow. Personally, I'd miss creating my own graphics on the fly at the same time I'm animating.
Regardless of method, there's nothing like getting objects moving and increasing complexity in your data to shake out interaction questions and details.
Early and often
In touch-based design, prototyping early and often is critical. When your team is deep in coding it's helpful for someone on your team to be able to do quick animated prototypes to speed decision making with stakeholders and check-ins with users.
Using animation it takes far fewer annotations and arrows to communicate most gestures and interactions - particularly if they have complex outcomes. And, in products where it takes a long time to code and physically prototype your interactions, it can save months of programming iteration by allowing early testing of the gestures and actions that are critical to your user experience.
In a few projects I've even done away with complex static documentation - instead storing these animations in a directory for engineering to reference as they build. We even deconstructed a few of them to see how we might improve them when we got to the code environment. That's the first time I've gotten to pore over my animations on a code level in a long time and we all found it to be powerful way to collaborate. Being able to work over your algorithms via animation prototyping - priceless.
I remember a complex mobile project in which I ended up having to add a series of very elaborate video and audio inputs to simulate the complex functionality of the app. The behaviors we were testing were very new to users so it was critical to get into some detail so that the engineers and users understood the problem we were trying to solve - attracting attention for the most critical next action when interrupted mid-flow. A couple of quick design tests later - and the winning solution was immediately evident. Usually, to find this kind of data, you have to wait until you're far enough along to have some fairly complex features up and working. This saved us several weeks of Agile feature iterations. Yea!
Moving from static to animated
Below you can see 3 scenarios from the Nokia mobile product. We began with the static versions to quickly check viability with engineers, asking, "Is that possible" in our scenario planning workshops. Then when we had good directions (met our business goals and were technically feasible) we animated them quickly and threw them on the phone to see how they performed. If they provided good user and stakeholder feedback - the feature was added into an Agile cycle.
Navigation carousel (scenario 1)