Animation By Design

・Travis

Animations are an important part of any modern user experience, but they are difficult to create and get into production. They shouldn't be. Here's how we can get there.

Producing great UX animations needs to be a design-first process but, unfortunately, in today’s world the fate of such things are in the hands of developers. This is largely due to the fact that such things as a hit area, a toggle button, or an activity indicator are all added to an app or website by writing code. It is the developer who is responsible for writing that code. Furthermore, the developer is ultimately the gatekeeper – and in a way the acutal product manager – for what goes into a product based on things like capacity, capability, or looming deadlines. Getting a UX animation into a product is currently a code-first process.

Great UX Animations

UX Animations can come in any shape or form such as buttons, switches, activity indicators, motion graphics, onboarding, and much more. When leveraged well, they breathe life into any system or interface, providing users with a more engaging experience that seamlessly aligns with their behaviours and expectations. If you look at any of today’s best products, you’ll see they all use animation to make their experiences better.

  • Instagram Layout – A slick onboarding animation.
  • New York Times – A lovely subtle animation of the loading screen.
  • App Store – Check out the touch of class on the color of the X button.
  • Headspace – This app is full of elegant ambient animations.

Great UX Animations are everywhere and they are actually really difficult to produce.

Why UX Animations are Code-First

The answer to this lies in two places: the nature of interactive animations, and the need for those to be driven by software. By their very nature, interactive animations are non-linear; they may have a start and end state, but how they get triggered and in which direction they play is wholly dependent on how someone has interacted with them. Accommodating this non-linearity requires an inherently non-linear medium for handling logic and state transitions, and today the best means for this is software.

Interactive Animations are Non-Linear

First any UX animation is inherently dynamic and most often non-linear. A switch, for example, has two animations in it… the animation from OFF to ON, and the animation from ON to OFF. A button on a website can have many different states – off, on, hovered, clicked – between which its appearance can change. An onboarding animation can play forwards, or backwards, depending the step to which a user has swiped or clicked. I think you get the point…

threeStateButton
A button, exported from Flow with unique animations between each of 3 different states.

Code is Dynamic

Triggering an animation can come from any number of inputs such as touches, clicks and scrolls (e.g. user interaction), or from other means such as data/logic which includes time, progression, and other value-based triggers.

Check out the gorgeous dynamic progress bar on the right. harvest.corto-olive.com

Code is Non-linear

With code, you can set up various states and styles and trigger transitions between them. Two very simple examples are using CSS for an tag and setting up a UIButton in Swift. In CSS, you can set the style for the normal, disabled, hover and selected states of a button.

multistatebutton
Three states of a button from our site: normal, hover, pressed.

There are many UI elements that have multiple states, and managing the logic behind those is exactly why we need to use code for these elements.

Code is Lightweight

Traditionally, if you wanted to get an animation into your app you might export an image (aPNG, GIF) or a movie and have a player trigger that at the right time – for example in a launch animation. With the increasingly high-res displays on mobile, this means your assets need to be huge, causing bloat in your app. With code, a simple animation ends up being a fraction of the size, can play back at scale and even have higher frame rates depending on the device.

Catch-22

Interactive elements like buttons, switches, spinners, screen transitions, and so on, should always be driven via software – you don’t want a video player sitting in every button and element in your app – that’s just nonsense.

So, shipping UX animations is limited by the need to be written in code which means that the production of those animations is dictated by the software development process. As a result, if a developer doesn’t have the capability or time to re-create an animation to spec, then the production of UX animations truly is guided by the development team. But, the critical benefit of UX Animation is that it makes the user experience better and should fundamentally be guided by the nuance, style and understanding of how it’s going to impact the end-user.

UX Animation Should be Design-First

The major hurdles to getting UX animation into production are cost (time/money) and accuracy. No matter how detailed a “design spec” is, recreating animations from scratch in code is time consuming, costly, and ultimately inefficient.

To break through this barrier, the design side needs to be responsible for production – i.e. it needs to be generating production-ready software. When this happens designers create shippable concepts and developers are responsible for evaluating the code and integrating into their projects (and maybe making some minor tweaks along the way).

The process becomes one where designers create and test in as-close-to-live environments as possible.

[Show design in sketch, animated in Flow, working in iOS]

A design-first approach brings with it immense value. First, you see increased productivity through a streamlined workflow – you eliminate tools, hours of documentation, and painful meetings. Second, you remove the need to “rebuild” a design from scratch which eliminates tons of dev hours. Third, you speed up iterations when design can respond to feedback without having to wait for dev production to see and test in-situ.

Depending on your team, and what you’re producing, you’ll start to see any (or hopefully all) of these benefits:

Higher margins – produce same quality product with far less effort.
Better products – spend extra time on making the product better.
Smoother workflows – eliminate needless back and forth. Happiness – Design and dev teams that ❤︎ each other again.

Conclusion

Animations are incredibly important in today’s market – the best products differentiate themselves through their user experience, with some products even outdoing others that have more features but a haphazard interface. That said, today’s fairly standard code-first process for making them is ineffective, cumbersome and costly.

Shifting the responsibility of production to the design side means that the designer (i.e. the design tool) generates shippable work – with little effort on the dev side for testing and validating. This results in the elimination unnecessary back and forth between design and development teams, with the output being higher quality products and higher margins.

Designers can focus on what they’re great at, Developers can focus on what they’re great at, and everyone is happy, and they love one another, and their jobs, and the customers are happy, and the users are happy, and there’s joy everywhere.

Try Flow For Yourself

Slack logo

Connect. Learn. Share.

background Made with Flow.
underscore Made with Flow.
line2 Made with Flow.
line1 Made with Flow.
circle Made with Flow.
hit Made with Flow.

result(s) found for “”.