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?

  • What does the OP mean by "jQuery animations"? Just animations in general? Why is jQuery mentioned specifically? Does the OP understand that jQuery is just a library? – Rahul Feb 9 '12 at 14:55
  • @Rahul: The OP asked about jQuery ones, which is obviously limiting. Thus, I'm interested in learning about ways to show any animation on a wireframe. – dnbrv Feb 9 '12 at 15:11

11 Answers 11


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.

  • Yes! Component libraries are good for that. Helps build up a shared vocabulary of interactions. – DA01 Feb 9 '12 at 16:18
  • 1
    But don't just stick reusable components in every new prototype you make. Determine whether eg. your date picker needs to work exactly the same way for this project and tweak it. It's important to sweat the details on interactions like that. – Rahul Feb 9 '12 at 16:43
  • Yes, a component library should be consistent per PRODUCT, but cross products you may very well need a wide variety of components for each task to accommodate the particulars of that particular product. – DA01 Feb 15 '12 at 16:13

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.

  • I agree that a proper prototype is ideal for developers. I'd probably encourage a UX person to learn HTML, CSS and JS rather than Flash and PDFs, though. The closer the prototype is to the actual medium it will be built in, the better. – DA01 Feb 15 '12 at 16:14

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.

  • What are those "specific icons/symbols"? – dnbrv Feb 9 '12 at 15:35
  • Looking back I have generally used similar icons that would indicate a video but with additional text specifying that this is an animation. The rest of the context would be in the storyboard. – Sheff Feb 10 '12 at 11:38

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.

  • I asked about all kinds of animations not just page transitions in wireframes not prototypes. – dnbrv Dec 10 '12 at 15:23

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.

  • 1
    The problems I have with those tools is that they are not the same medium as the interaction will eventually be in (if we're talking web design). So it can help communicate an interaction, but it's likely not the same interaction that will eventually be built so one has to weigh that drawback. – DA01 Feb 9 '12 at 16:20
  • Wireframes are static. Once you introduce transitions it becomes a prototype. – dnbrv Mar 3 '12 at 18:09

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.

  • Wireframes are static. Once you introduce transitions it becomes a prototype. – dnbrv Mar 3 '12 at 18:08

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.