Transitions between screens and states: how motion explains where you've landed

When one screen instantly replaces another, people have to rebuild the picture from scratch: is this a new page, a window on top of the old one, or the same page scrolled down? On a phone the whole screen changes, and the link between “before” and “after” is lost. Nielsen Norman Group notes that accordions, anchor links and full-screen menu overlays that appear instantly can be disorienting: without an animated cue it's unclear whether a new page opened or something else happened.

A transition solves this in a fraction of a second: it shows where the new screen came from, where the old one went and which way leads back. It isn't decoration but part of navigation — just like breadcrumbs or a Back button. The previous lesson in this track covered micro-interactions on individual buttons and toggles; this one is about whole screens and large state changes.

It helps to think of an interface as a space people move through. Then every direction gets its own motion, and that motion is the same across the whole product. Nielsen Norman Group describes this kind of animation as an easily understood spatial metaphor for the user's location in the information space. A shopper's path through a catalog is the clearest example.

The core rule is reversibility. Apple's Human Interface Guidelines give an example: if someone reveals a view by sliding it down from the top, they don't expect to dismiss it by sliding it to the side. Motion sets an expectation, and the dismiss gesture has to match it. That's why at InterLAB we define the transition system alongside the design system: one set of motions and durations for the whole product rather than an eyeballed decision for each screen.

The strongest continuity technique is the shared element transition. Someone taps a card in a catalog, and instead of disappearing it expands: the image grows into the header of the new page, the title moves into place, and the rest of the content fades in around it. The eye follows a single object and never loses it, so the question “did I tap the right thing?” simply doesn't come up.

The same principle works inside a single screen, when what changes is a state rather than a page:

• Accordion: the section grows smoothly and the content below slides down instead of jumping — it's clear what opened
• Tabs: the active indicator slides under the new tab, and the content swaps with a short fade
• Removing from a list: the row collapses and its neighbours close the gap — it's clear what went away and that nothing broke
• Adding to a list: the new row pushes its neighbours apart and fades in place, instead of appearing with a jolt of the whole list

To keep these rearrangements smooth even on a modest phone, developers use a technique called FLIP. The name comes from the first letters of four steps:

For a long time smooth page-to-page transitions were mostly the privilege of single-page apps: on a regular site, following a link simply showed the new page. The View Transitions API changes that. The browser takes a snapshot of the old state, applies the new one and animates the difference. By default that's a cross-fade, and elements that share the same view-transition-name on the old and new screen can be animated from one position to the other — that's how shared elements are built on the web.

In mobile apps much of this is already built into the standard navigation components, and it's better to rely on them than to invent your own: users know these motions from every other app on their phone. For a distinct task on iOS, Apple's HIG recommends sheets and popovers. On Android, Jetpack Compose builds shared elements from SharedTransitionLayout and the sharedElement and sharedBounds modifiers, while the predictive back gesture shows an animated preview of the screen the person will return to before the gesture is complete.

The worst transition is the one that finishes with nothing to show: a blank white screen or a lone spinner. People can't tell whether the app is working. The fix is a skeleton screen: the new screen arrives immediately with grey blocks where the title, image and lines of text will be, and the data fades in as it loads.

Nielsen Norman Group recommends skeleton screens for page loads with a wait under 10 seconds, and a progress bar for longer operations. A skeleton should mirror the structure of the upcoming page: a bare frame of header and background with no content outlines is, by NN/g's assessment, essentially no better than a spinner.

The second technique is optimistic navigation: the transition starts the moment someone taps, without waiting for the server to respond.

• The screen opens instantly with what's already known: from the card in the list we know the name, image and price — show them straight away
• Everything else loads into the skeleton in its place, without layout jumps
• A loading error is shown inside the new screen with a Retry button, not as a silent jump back

A transition costs people time on every tap, so duration matters more than spectacle. Nielsen Norman Group considers 200–300 ms appropriate for substantial screen changes such as a modal moving into view, treats 400 ms as a very slow animation reserved for big movements, and notes that around 500 ms motion starts to feel like a drag. The same article points out that elements entering the screen usually get a slightly longer duration than those leaving it.

• Animate transform and opacity — as web.dev recommends, the browser handles them more cheaply than changes to size and spacing
• Don't run heavy effects mid-transition: full-screen blur, large shadows
• Test on an inexpensive Android phone: a juddering transition is worse than none at all
• Don't block input: if someone taps Back mid-animation, the transition should interrupt and reverse, not play out to the end

Reduced motion deserves its own attention. If someone has turned it on in their system settings, a site can detect it through the prefers-reduced-motion media query. WCAG success criterion 2.3.3 describes the requirement: motion animation triggered by interaction should be possible to disable unless it is essential. For transitions this means replacing slides, scaling and a flying card with a short fade in place. The meaning — “the screen changed” — stays, and the motion that can cause nausea is gone.