By the end of this lesson you can
- Design transitions between screens and states.
- Choose transition types that support the navigation model.
- Specify animations so developers can build them accurately.
The idea
Transitions connect one state to the next. They should reflect the structure of the product.
Common transition types
- Push / slide: moving deeper into a hierarchy (list to detail). Back reverses the direction.
- Slide up / sheet: temporary tasks such as composing a message or choosing an option.
- Fade / cross-fade: switching between peers, such as tabs, where there is no direction.
- Shared element (container transform): an element, such as a card, grows into the next screen, keeping continuity.
- Skeleton to content: placeholder content fades into real data.
Specifying animation
Developers need: what moves, from where to where, duration, easing curve, delay and stagger, and the reduced motion alternative. Use a table or annotated frames. Short screen recordings of prototypes help, but always include numbers.
Performance
Animations that move or fade elements (transform and opacity) run smoothly. Animating layout properties such as width and height can cause jank, so check with developers.
Why it matters in real projects
Transitions tell people how screens relate. Consistent transitions build a spatial model of the product, so people always know whether they went deeper, opened something temporary or switched sections. Precise specs prevent animations being dropped or built differently on each platform.
A realistic example
A recipe app uses a slide-left transition for every screen change, including switching tabs and opening the filter sheet. People feel they are going "deeper" when they are not, and back behaviour feels inconsistent.
The designer defines rules: slide for hierarchy, sheet for temporary tasks, cross-fade for tabs and a container transform from recipe card to detail. A spec table gives developers durations and easing. The app now feels coherent, and testing shows fewer people getting lost.
Step by step
Map relationships
For each navigation, note whether it is deeper, temporary or peer.
Assign transitions
Choose a transition type for each relationship.
Prototype
Build key transitions with smart animate or similar.
Write the spec
Document properties, durations, easing and stagger.
Check performance
Prefer transform and opacity; review with developers.
Define reduced motion
Specify the fallback for each transition.
Common mistakes
Mistake One transition for everything.
Instead Match transitions to relationships.
Mistake Specs with only a video.
Instead Include exact numbers.
Mistake Animating layout properties.
Instead Use transform and opacity where possible.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 1 h
Transition system
Define a transition system for a small app.
Steps
- List navigation relationships.
- Assign transition types.
- Prototype three transitions.
- Write the spec table.
Deliverable
A transition rules table, spec and prototype link.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Transitions show how screens relate.
- Use slide, sheet, fade and shared element deliberately.
- Specify motion with numbers.
- Prefer transform and opacity for performance.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
- Transitions (opens in a new tab)Material Design 3
- Animations and performance (opens in a new tab)web.dev
Your notes
Marking complete updates your course and roadmap progress.