User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I came across a question on Quora about jQuery animations in wireframes, which got me thinking about the general conventions in depicting any animation in static wireframes. I've been using either call-outs or supplemental documentation to explain animated elements but those obviously don't do the justice.
Is there a better way or is it the inherited "feature" of abstractions?
Wireframes are a terrible place to try to describe animation. The closest you can get is something abstract like interactive sketching notation, but that requires the viewer of the wireframe to understand the notation style and it can only communicate very limited transitions.
Use a wireframe to outline the structure of a page. Treat it like a sketch, even if it's a high fidelity sketch made in eg. Axure or Balsamiq Mockups.
Use an interactive prototype (preferably created in the same environment the final product will be created in) to illustrate any kind of interactivity, be it the specific hover effect on a button or actual screen transitions and animations.
If stakeholders are having difficulty understanding a particular interaction approach and you don't have time or resources to make a prototype, one short-cut I've seen is to use an example of the interaction "in the wild" if you can find one. (Ethan Marcotte's responsive web design, for example.) Obviously you must be clear that what you're referring to is not the project solution, just an example of how a similar approach has been implemented in other products.
For the long term, one big way to make depicting interactivity more efficient is to modularize your interface elements. For example, if you made a date picker for your last project, save it and use it later in a prototype. Don't reinvent the wheel with every interaction.
This is one of many reasons why wireframes are inadequate as interaction documentation. The answer is simply that they can't. You need a prototype--ideally in proper presentation layer code--to properly communicate the interactions.
I've come across this numerous times, and I can certainly tell you what NOT to do - if you're creating a static or spec prototype, it's generally not worth to include any animation, expecially if the file will function as a basis for development. Not only will it confuse the programmers, it makes it almost impossible to use the file as a basis for documentation (say, writing SCRUM stories).
One solution I did try is to show the animation in a storyboard format, but this didn't go down too well with the programming folk, as it confused them even further.
What I would suggest is to keep animated prototypes seperate from the static ones, and simply adding links to an external file in the element description field. This way you'll be able to give one file to the marketing department or the product manager, and the other one to your friendly neighbourhood specifications guy and programmers.
Small animations are actually possible. I have successfully shown how form fields should behave in an animation that is inside the wireframe document. The final document was an interactive PDF with the embedded flash demo.
The engineers found it extremely useful because I didn't actually annotate all the error states or behaviors- the annotation was the animation.
This doesn't require you to be good at flash or anything, InDesign has some custom animation and timing panels that come in handy whenever I find that the animation will do a better job of explaining the interaction.
Down side- slightly more time consuming. But totally worth it.
In static wireframes I generally use callouts and include a specific icon/symbol to denote animation.
If the animation is of significant importance I would provide a storyboard of the animation with the wireframe.
Keynote allows to present simple page transitions and more complex animations. Many of which display on the iPad app, which works nice when presenting material to stakeholders. Warning: iPad Keynote app will only display BuildIn and BuildOut animations.
Simple animations can be also created in the POP prototyping app.
Standard transitions can be annotated in a Functional Spec document. For example a list of transitions and behaviors can be found on Android and iOS User Experience guideline websites.
Depending on how complicated the animations are you could use Keynote or Adobe After effects or Flash to demo the animations. You could also in the annotations refer to other live web sites. I sometime use the demo on Tweenlite to explain the transitions and animations.
I have simply used Microsoft Powerpoint to create animations for interaction. It can build a story or a set of tasks for a requirement. It will be slightly time consuming, but it is fun,simple and cost-effective.
The interactions can be automated instead of real clicking as an interaction, which is good with powerpoint.It helps stakeholders and developers to understand the logic and can quickly address concepts as they open up the deck, and the flowing automation works effectively.
As @Rahul said - wireframes are the wrong place to depicted animations. The only way would be a combination of describing words and arrows. Every single step further would be either to detailed for a wireframe or not as desired.
I've run into this problem as well, and usually to save time ... i storyboard the action in wireframes. If time wasn't an issue I would create Hi-Fi actions in Fireworks.
