At Clarity Conference in San Francisco, Rachel Nabors talked about UI animation and how to document animation within a design system. Here are my notes:
- Rachel has worked on Dev Tools Challenger, Alice in Videoland, and helped with the motion portion of Salesforce’s Lightning Design System.
- Animation is important for consistent branding and UX. It makes people feel like there are physical laws that your UI adheres to.
- Challenges for consistent animations: communication issues, inadequate deliverables for implementation, and a lack of respect. It’s hard to find good animation guideline examples online.
- Designers want animation docs to be thematic, theoretical, and educational. Developers want them to be granular, component-based, instructional, maintainable.
- With documentation, you can show what’s there and why, provide smart defaults, provide unity (choreography), and guidance for future contributors.
- Animations designed in code can often look too mechanical, sort of like designs that start in code.
- Developers loathe getting gifs and movies, then are told “here, just make this.”
- Easing: Rate of change: ease-in, ease-out, bounce. Cubic beziers help make custom animations.
- Fades and color changes look best with more linear, subtle curves. Bounces increase animacy and add an air of fun.
- Timing: animation can’t happen without a duration. For the Lightning Design System, they established a motion modular scale for animation timing.
- Timing limitations: try to stay inside 70 to 700 milliseconds. 200-300ms is a sweet spot. Shorter durations for fades and color changes, longer durations for large movements, use milliseconds instead of seconds.
- Properties: what’s being changed?
transform are the most performant properties to animate on the web.
- “The art challenges the technology and the technology inspires the art.” – Pixar. Push the limits of what’s technically possible.
- Combine easing, timing, and properties to make an animation vocabulary
- Making an animation vocabulary: “zoom” vs “zoooooooooom” pay attention to how people communicate animation. Pave the cowpaths when establishing your animation language (i.e. look at Keynote’s motion transition effects). Use your words to communicate animation.
- Storyboards – began in film but can be used on the web as well. Sometimes storyboards can be more useful than a video for documentation. Define the actions: when [this trigger happens], do [this action]. Storyboarding tools: go old school with Post-Its, Rachel has a storyboard template, storyboardsthat.com.
- Animatics involves demoing animation.An animation is worth a thousand meetings. They’re not deliverables: don’t throw videos at developers. They’re guidelines and they don’t provide people with actionable content. Animatics tools: Keynote, AfterEffects, Principle app, Stop Motion app
- Prototypes – real working examples can be great to demo animation, but they’re bad for documentation. Prototyping tools: Native-oriented tools: principle, pixate, web-oriented: Invision + gifs, UX Pin, Framer.js
- Combine storyboards, animatics, prototypes to provide solid documentation on look and feel as well info on how to reproduce animations
- Generating buy-in: not everyone is as excited about animation as you. Group documentation can help people feel involved. Wireframe exercise. Cultivate and champion animation: get more people on board. Get a co-conspirator on board.
- Do it anyways. If people aren’t caring about animation, just make it happen anyways.