Motion Design

This guidance defines how motion should be used in our product UX.

Motion should support usability, not decoration. In our products, it is mainly used for transitions, feedback, loading states, and small interactions. It should feel calm, quick, and functional.

This guidance should be maintained as part of the design system. Updates should be reviewed for consistency across UX, design, and implementation.

Scope

This guidance applies to product UI motion and interaction feedback across our web-based experiences. Any deviation from the default approach should be based on usability needs, technical constraints, or platform conventions.

Usage rules

Motion triggered by user input should ideally begin within 0.1 seconds to preserve a clear sense of cause and effect.

The more often an interaction occurs, the more restrained its motion should be. Motion must not block input or delay task completion. Animations should be interruptible. If the user triggers a new action, the UI should respond immediately. Where relevant, motion should also reverse cleanly when state changes quickly.

Microinteraction structure

Small interactions work best when they follow a clear structure.

1. Trigger The event that starts the interaction, such as click, tap, hover, scroll, drag, or a system condition.

2. Rule The logic that defines what happens after the trigger.

3. Feedback The visible response, such as a state change, validation, progress indicator, or confirmation cue.

4. Loops and modes How the interaction behaves over time or remains active. Repeated or long-running interactions should remain subtle.

Before adding motion, ask:

• What purpose does it serve?
• Where is the user’s attention likely to be?
• Is it user-triggered or system-triggered?
• How often will this interaction occur?

Use motion when:

• a transition helps users understand what changed
• feedback confirms a completed action
• movement helps users stay oriented
• an important change needs attention
• progress or activity needs to be shown

Avoid motion when:

• it is decorative only
• it uses bounce or elastic effects
• it moves elements across large distances
• it appears on every page load without clear value
• it slows repeated workflows

Time and easing

Motion should feel quick and responsive. Default delay should be 0 ms. Use delay only when it supports hierarchy or comprehension. Staggering should be subtle, brief, and limited to small groups of related elements. Avoid delay on frequent, critical, or task-focused interactions.

Standard durations

• Feedback states: 80–150 ms
• Component transitions: 150–200 ms
• Overlays: 200–250 ms

Standard easing

• Enter: ease-out
• Exit: ease-in
• State change: ease-in-out

Direct, user-triggered motion can feel slightly sharper. System-triggered motion should usually feel quieter.

Loading states

Loading motion should communicate progress without dominating the screen.

• Prefer skeleton screens when a layout preview is useful
• Use subtle spinners when the structure cannot be previewed
• Avoid aggressive pulsing or excessive shimmer
• Keep loading motion secondary to content

Spatial logic

Motion should reflect where an element comes from and where it belongs.

Examples: Drawers slide in from their attached edge Dropdowns open from the trigger Accordions expand in place

Implementation

Prefer CSS transitions for UI motion where possible. They are sufficient for most UX motion in business applications and support a lightweight, consistent, and maintainable implementation.

This reflects the shared recommendation of the frontend developers in Team Vega and Team Sentinel, who agreed to implement motion with CSS rather than framework-specific solutions, mainly for compatibility reasons.

CSS is best suited to subtle changes in opacity, transform, and colour. Motion that requires complex choreography should usually be simplified.

Motion should feel lightweight and responsive in real use. Prefer animating opacity and transform. Avoid motion that causes layout shifts or slows dense interfaces. If motion reduces perceived performance, simplify or remove it.

Preferred properties:

• opacity
• transform
• background-color
• border-color
• color

Avoid where possible:

• width
• height
• top
• left
• box-shadow
• filter

Design tokens

Shared motion tokens help maintain consistency across products.

Suggested tokens:

• —motion-sm: 80ms;
• —motion-md-out: 120ms;
• —motion-md-in: 160ms;
• —motion-lg: 200ms;
• —ease-enter: ease-out;
• —ease-exit: ease-in;
• —ease-standard: ease;
• —distance-sm: 8px;
• —distance-md: 16px;
• —distance-lg: 24px;

Accessibility

Accessibility must always be considered in motion design.

• Support prefers-reduced-motion
• Remove non-essential movement instead of only slowing it down
• Keep fades subtle
• Avoid parallax, zoom-heavy transitions, and large directional movement
• Never rely on motion alone to communicate meaning
• Ensure success, error, and focus states remain understandable without animation

Handoff

Requirements

Motion should be specified clearly for implementation.

Include:

• duration
• easing
• delay, if needed
• animated property
• start and end values
• trigger state
• reduced-motion behaviour

Review checklist

Before implementation, confirm that the motion:

• serves a clear purpose
• is quick and restrained
• uses approved timing, easing, and properties
• works with reduced-motion settings
• does not rely on motion alone
• can be implemented with the preferred approach