Guidelines

Motion

Bringing layouts to life.

Motion can introduce elements of delight and activity for users. Used sparingly, it can focus their attention and help them navigate through the UI. Here we discuss motion generally, the specific page-level navigations available on iOS and Android, and custom animations.

General motion

Principles

Deciding what type of animation to use is more art than science. They should be quick but not jarring. To achieve this balance we generally use short durations for animations with smaller items and those moving smaller distances. Larger objects and objects moving larger distances will use longer durations.

Easing

For those familiar with easing values on the web these are slightly more aggressive than a browser’s animation-timing-function defaults.

Easing tokens are available for use in SCSS and Javascript. iOS and Android should use their platform’s built-in easings.

ease-in

cubic-bezier(0.50, 0, 1, 1)

Moves from slow to fast.

ease-out

cubic-bezier(0, 0, 0.40, 1)

Moves from fast to slow.

ease-in-out

cubic-bezier(0.45, 0, 0.40, 1)

Moves slowly on both ends.

Duration

Determines the length of the animation. The length of the animation usually corresponds to the size and distance of the animation.

Duration tokens are available for all platforms.

Token

Duration

duration-1

75ms

duration-2

150ms

duration-3

200ms

duration-4

250ms

duration-5

300ms

duration-6

350ms

Examples

These first three are generic examples of motion. Click each to toggle the animation.

Color transition

duration-3 with ease-in

Pop-up

duration-2 with ease-out

Slide

duration-5 with ease-out

And these three examples are based on interactions currently used in Thumbtack products.

Preferences saved.

Banner slide down/up

duration-3 with ease-in

Training

Waitng for response

Hover/touch scale

duration-2 with ease-out

1 Room
2 Rooms
Standard
Deep
Window
Fridge

Skip fade out/in

duration-4 with ease-out


Page-level transitions

iOS and Android each ship with a number of stock page-level transitions. In this guide we’ll define which transitions are available on each platform, when each should be used, what’s involved in building custom transitions, and how transitions should be communicated by designers to developers in their layouts.

Examples

Click on any of the letters to toggle the animations. Note that the transition speeds used in these examples has been slowed to better convey how the transition works.

iOS

Push

“Pushes” a page out of the way for the other, sliding in from the right to go deeper into the UI.

Page sheet

A page slides from bottom and stacks above parent page.

Full screen modal

Page slides from bottom, overtakes entire screen.

Android

Push

“Pushes” a page out of the way for the other, sliding in from the right to go deeper into the UI.

Full page

Page overtakes unrelated existing page with slight grow.

Parent child

Transition from a child expanding to full screen.

Building custom native transitions

Stick with stock

We generally recommend using the stock animations that are pre-packaged on the different platforms. The primary reason for this is consistency.

Users get accustomed to page-level interactions. They become conventions. Introducing a new way for the user to interact, or changing existing ones, can be disorienting and confusing, particularly when a standard transition will do.

Also, these interactions are changed occasionally in OS releases. If we bypass the stock animations our users will not benefit from these updates, again distancing them from the convention.

Custom

A custom transition can be built into a feature or flow if it uniquely improves the user experience as they pass through it.

For example, as of late 2019, the iOS App Store home used a custom navigation that pushes the article out and over the link. Instead of an overlay sliding from the right or bottom the user has the sense of moving deeper into the UI, experiencing the hierarchy in a less jarring way.

Custom transitions like these should be vetted with prototypes, user testing, and native developers who will determine the technical feasibility of building and maintaining it.

Communicating motion in Figma

The inability to communicate motion in static layouts has been a long-standing problem in the design world. In the absence of this information it is often up to the native developer to decide how to implement it.

To alleviate this problem with page-level transitions we recommend designers to use the motion annotations we’ve provided in Figma.

Example transition annotations available in Figma.

transition annotations

Was this page helpful?

We use this feedback to improve the quality of our documentation.