Five Questions to Ask Yourself Before Designing an Animated GIF

Five Questions to Ask Yourself Before Designing an Animated GIF

In the world of user experience and product design, animations are quickly becoming the new status quo. For example, Google’s Material Design Guidelines are ripe with animation philosophy and animations showing desired interaction patterns. Prototyping services like InVision are pushing animated GIFs as the answer to displaying transitions between user interface states. Visit any design community website and you’re bound to find a large collection of animated GIFs. Dribbble even has a whole section of their site dedicated solely to these fun animations.


Screenshot via Dribbble

Why have these animations become so popular? The time taken to create animations often outweighs their benefits.

Designers create animated GIFs for two main reasons. The first reason is solely to provide entertainment or visual aesthetic. For example, many of the above animations are illustrations with some extra animation flair. You commonly find such animations on brochure websites or marketing pieces.

The second reason designers create animations is to demonstrate functionality to developers or clients. Many user experience and product designers have turned to the animated GIF as a medium for showing design specifications. While static wireframes and mockups are great for portraying an app’s static states, these mediums struggle to communicate what should happen when the product transitions between these states. Some prototyping tools like InVision and Flinto offer preset animations. However, preset animations can’t capture the custom animations that designers often envision. On the other hand, custom animations usually entail much more development complexity and time. Are custom animations worth the trouble?

Why Animate?

Google’s Material Design Guidelines do a fantastic job of explaining the benefits of including animations in your app’s interaction design: “Use motion to smoothly transport users between navigational contexts, explain changes in the arrangement of elements on a screen, and reinforce element hierarchy.” The web is ripe with examples of how animations inform and enhance a product’s usability, and some of these animations have even become expected behavior. Animated scrolling, shown below, is one of the most common examples.


Without the animation between two points on the screen, the transition is jarring and, as UX aficionado Adrian Zumbrunnen explains, hard for the user to process. Animations can also be beautiful and make a product’s brand and identity truly unique. Tim Caynes, principal designer at Foolproof, shows below that the design community is quickly approaching design singularity. Because product design is converging into a single aesthetic standard, opportunities to stand out are few.


Andrew Wilkinson, founder of Metalab, recently explained just how important it is for your product to break away from this design singularity. In his Medium article “Slack’s 2.8 billion dollar secret sauce,” Wilkinson explains that Slack’s unique appearance and personality — not its features — are responsible for the app’s success. He candidly admits that the app’s feature set is “almost identical to every other chat app.” Thus, building unique animations into your product could help it escape design singularity and remain memorable.

The Downsides of Animations

Building Animations is Hard

With beauty comes overhead. As clear as the benefits of animation may be, the process behind actually building animations into a product is anything but clear. For example, Google uses the following sample animation to promote maintaining visual continuity when transitioning between states:  


While this is a beautiful and usable transition, it is also a front end developer’s worst nightmare. I asked a developer on my team if we could build a similar animation. His response: “I could spend three weeks figuring out how to build that animation, or I could build you a feature.”

Prototyping Animations is Time Consuming

Imagine after spending hours perfecting the most beautiful mockup and documenting every small piece of its functionality, you realize you still haven’t explained that animation you were so excited about. You also realize that you need to make those pixels move. Looks like you’re working late.

While static mockups take time to produce, animations take even longer. Creating a perfect animation (with natural acceleration, motion blur, etc.) is almost as time consuming as coding it. Existing tools to create these animations are either limited, or have a high learning curve (like learning how to use Photoshop from scratch). You obviously shouldn’t shy away from picking up a new skill just because it is time consuming or difficult to learn. I’m not saying that animated GIFs are never worth the time — it’s not that simple.


In conclusion, here are a few questions you should ask yourself before you even consider firing up your favorite motion graphics editor to prototype an animation:

1. Is there a more efficient medium to demonstrate this animation to developers?
We designers can sometimes be control freaks. We are detail oriented — that is what makes us great at our jobs, and is also why we cringe when a feature is not built exactly how we envisioned it. So our natural instinct is to prototype functionality as close to the real thing as possible. We often think that if we design a prototype with high enough fidelity, then we can just throw it over a wall to the developers and they will do the rest.

What happens though when you send your perfect animation over to your developers and they tell you they can’t build it, or they point out a flaw in the animation, or prove that it’s not even necessary? You may have wasted hours of your time.

In short, you should strive to demonstrate app functionality with the lowest level of fidelity possible. For example, I created the following animated gif of a paper prototype in just five minutes:


It’s not pretty. It is enough to demonstrate the idea to a developer and serve as starting point for coding the actual animation into production. You won’t be able to use paper to demonstrate more complex interactions. However, if an animation is highly complex, you should re-evaluate whether it is actually making your product simpler to use.

2. Will the animation achieve its intended purpose without the fancy effects?

Rebecca Ussai’s “The Principles of UX Choreography” explains that natural animations are comprised of numerous small details: inertia, motion blur, hinting, etc. If an animation’s purpose is to improve a product’s usability, these extra details are more trouble than they are worth. Designing them takes time and building them takes even more time. Will an average user with an untrained eye even notice these details? Forego the bells and whistles. Instead, show the stripped down animation to actual end users. If it improves the product’s usability, think long and hard about whether the effects are necessary.   

3. Are you trying to demonstrate a brand new design pattern?

If the animation you’re envisioning is similar to one you have seen somewhere else, you should first see if the existing animation is enough to communicate your vision to developers, rather than prototyping it from scratch. If the animation you are envisioning is drastically different from any animation you have ever seen, revisit question 2.

4. Is the animation even possible to build?

Animations that are possible to build on native often aren’t possible to build in hybrid or mobile-web apps. Depending on your development framework, animations could also significantly impact performance. As a designer, you probably won’t immediately know which animations are possible to build and which will slow down performance. In this case, you should communicate with your development team early in the design process. These discussions may lead to a chicken-or-egg type conundrum — how will a developer know if an animation is possible, if you have not shown them the animation first? Here is where lower fidelity design approaches such as paper prototyping and sketching come in handy. It is also helpful to develop a standard animation language with your project team to discuss how UI elements should move and transform in relation to one another. For example, you might explain an animation by stating that a card “pushes” another card out of view. By combining these methods, you can often provide developers with enough information to make a decision about whether the animation is possible, or even the level of effort to build it.

5. How much will this animation separate my product from the competition?

One of the first things you should do when building a new product is evaluate the existing marketplace. Often, this simply comes down to using a whole bunch of products that try to solve a similar problem as your product. If you are entering a crowded marketplace with big name players (think Nike, Facebook, etc.) who have products with slick, natural animations, then you should place a premium on developing animations of similar quality. If you are early to the market and early in development, you should focus more on solving a problem and less on making the most beautifully animated UI.

Like What You See?

Got any questions?