UI animation: motion that helps, and motion that shows off

What motion is for

Three jobs. Anything that does not do one of them is decoration, and decoration on a screen the player opens forty times an hour is a cost.

1. Continuity. Showing where a thing came from and where it went, so the player builds a mental map of the interface rather than experiencing a series of unrelated screens.
2. Attention. Directing the eye to what changed, which is far more effective than making the changed thing bigger or brighter.
3. Confirmation. Telling the player their input registered, which is covered as its own subject in how a game tells the player it heard them.

Motion that exists because it looked good in the mockup fails all three, and it fails them repeatedly, because interface is the one part of a game the player sees on every single session.

Duration and easing as a system

Pick a small set of durations and easings, write them down, and use only those. Motion timed per screen by taste is how a game ends up feeling inconsistent without anyone being able to say why.

• Ease-out for entrances, ease-in for exits. Things arriving should decelerate into place; things leaving should get out of the way.
• Larger elements need slightly longer, because they travel further and a fast large movement reads as a jolt.
• Never linear for movement. Linear motion is the single clearest tell of unconsidered animation, and it is why default engine tweens look cheap.
• Overshoot sparingly. A small bounce suits a playful game and undermines a serious one, and it always costs time.
• Two or three durations is enough for a whole game. Fast, normal, slow.

Transitions that say where you came from

On a small screen especially, transition direction is often the only navigation cue the player gets. Making it consistent turns a set of screens into a place.

• Going deeper moves in one direction, coming back moves in the opposite one. Pick left-right or forward-back and never mix them.
• Modals grow from the thing that opened them where you can, so the connection is explicit.
• Tabs slide the direction the tab sits. Selecting a tab to the right should bring content in from the right.
• The back transition mirrors the forward one exactly. An asymmetric pair makes an interface feel unstable.
• Never cross-fade navigation. A cross-fade says these two things are the same screen changing, not you moved.

Animate the frame, not the content

The most common performance-adjacent mistake in interface motion, and the one that makes games feel slow rather than smooth.

• Never animate the thing the player is waiting for. If they opened the inventory to check an item, the item list should be there immediately. Animate the panel around it.
• Content fades in fast or not at all. A 400 ms fade on the data the player came for is 400 ms of delay wearing a costume.
• Do not animate layout. Moving and resizing containers is expensive and it makes text reflow mid-animation. Animate transform and opacity, which is also the cheap path in most engines.
• Let input interrupt. A player who presses a button during a transition should get the result, not wait for the animation to finish. This is the difference between an interface that feels responsive and one that feels like it is negotiating.

Stagger, and when it becomes a queue

• A small stagger reads as life. Twenty to forty milliseconds between items in a list gives a sense of arrival without feeling sequenced.
• A large stagger becomes a wait. Ten items at 100 ms each is a full second before the last one exists.
• Cap the total. Whatever the item count, the whole group should finish within about 400 ms. Stagger the first few and bring the rest in together.
• Never stagger something the player can act on immediately, or they will click an item that is still moving.

The tenth time, and the hundredth

Interface animation is reviewed once, in a slide, by people seeing it fresh. It is experienced hundreds of times by players who are not. That gap is where most motion complaints come from.

1. Make every celebration skippable, with a press that both skips and proceeds. Level-up flourishes, reward reveals, results screens.
2. Consider decay. The first unlock can be theatrical; the fiftieth should be brief. Some games reduce the sequence after a few repetitions and nobody complains.
3. Watch the death screen especially. A long animation after a failure is the moment sessions end, per difficulty, failure and the moment players quit.
4. Time the loop. Open the most-used screen, do the thing, come back. Add up the animation. If the round trip costs two seconds and happens forty times a session, that is your motion budget spent badly.

Idle motion: the first thing to cut

• Continuously animating idle elements pull the eye repeatedly toward information that has not changed. It is the opposite of what motion is for.
• Pulsing to draw attention works once, then becomes noise the player learns to ignore, at which point it is worse than nothing.
• Looping backgrounds and parallax on menus are fine in the front end and expensive on a HUD, both in attention and in battery.
• If it must breathe, make it slow and low contrast. Fast, high-contrast idle motion competes with the game.

Motion and performance

• Prefer transform and opacity. They are cheap in every engine; animating layout properties is not.
• In uGUI, an Animator per button costs every frame it is enabled, even idle. Use the built-in transitions or code tweens instead, per why your Unity menus tank the frame rate.
• Animating text is expensive, because the mesh regenerates. Animate a container holding the text where you can.
• Stop animations when their screen is hidden, which is free and frequently forgotten.

Specifying motion in a handoff

Motion is the part of a design that most often arrives as "make it nice" and comes back wrong. A spec removes the guesswork and takes minutes per transition.

That block, once per transition type rather than once per screen, is what turns a design into a build. It belongs alongside the states and anchors in designing game UI for Unity.

Every animation is a small tax the player pays each time. Charge it only where they get something back.

Reduced motion

• Offer a reduced-motion setting that shortens or removes interface transitions. It is a small feature that makes the game playable for people who get motion sick and welcome for everyone else.
• Reduced does not mean instant and jarring. Keep short fades, drop movement and parallax.
• Respect the platform setting where one exists, particularly on mobile.
• Keep camera shake, blur and screen effects as separate toggles, per game UI accessibility.

A motion audit

1. Record the path from the main menu to your most-used screen and back. Add up the time spent animating.
2. Count the distinct durations in your interface. More than four is a system problem.
3. Look for anything linear. Fix it first.
4. Open a screen and try to act during the transition. Does it accept input?
5. Find the content the player came for. Is it animating, or is the frame?
6. Trigger your reward flourish five times. Is it skippable?
7. Watch a HUD for thirty seconds without playing. What is still moving, and why?
8. Check the back transition mirrors the forward one on three screens.
9. Profile a menu opening on the target device.
10. Turn on reduced motion, if you have it, and check nothing became unusable.