Timing

Foundations / Timing

Intro

Timing refers to how long a component appears or disappears on screen, as well as any intentional delay between user input and the system response. The speed should be slow enough for users to notice changes, but fast enough to avoid unnecessary waiting.

General Principles

Generally, timing correlates with component size. The following sections explain how durations differ for small and large components.

Small Components

Small components usually contain less content and carry less visual weight, so users can process updates and changes quickly. Shorter transition times work well here—quick transitions help keep interactions brisk, reduce disruption, and let users stay focused on the main content.

Large Components

Large components often present more information, have greater visual prominence, and can cause more noticeable changes to the layout. Use longer transitions for these components. This gives users time to notice and understand the change, support cognitive processing, and integrate new information smoothly without feeling rushed or disrupted.

What to Consider

User Intent

Timing is directly related to the user’s intent and expectations. Well-timed transitions guide focus and provide feedback from the system to the user.

Enter and Exit

When a component enters (appears on the screen), a slightly slower transition helps users notice the change, understand the context, and prepare for interaction. By contrast, components often exit more quickly to reduce the delay and maintain a responsive feel.

Reveal Hidden Content

When a user hovers over an item for 300 to 500 milliseconds, this often shows intent to open the item or display hidden content. Revealing hidden content too quickly can cause accidental activations and confuse users, especially during casual cursor movement. On the other hand, waiting too long can make the interface feel unresponsive and interrupt the user’s workflow.

Timing Groups

You can group components by how long they take to appear on screen or respond to user input:

Note: 1 second = 1,000 milliseconds.

Fast (up to 100 milliseconds)

Interactions with components should feel immediate and seamless for users. This creates a sense of direct manipulation and responsiveness.

Change in the button state on hover – example of a fast interaction (up to 100 milliseconds display time)

An example of fast interaction timing is how a button responds on hover:

A. Entry: When the user moves the mouse pointer over the button, the interaction state changes from regular to hover, giving a visual indication that the component is interactive.
B. Exit: When the user moves the mouse away from the button area, the state returns to regular.
C. Display time: Each change in state should happen within 100 milliseconds.

Normal (100 to 1,000 milliseconds)

Components in this group handle slightly more complex operations.

Tooltip display – example of a normal interaction (100 to 1,000 milliseconds display time)

An example of normal interaction timing is tooltip behavior:

A. Entry: The standard time to display a tooltip with a mouse is 500 milliseconds. This prevents flickering or accidental activation when users move the cursor quickly. The same delay applies when showing a tooltip via keyboard. For touch interactions, tooltips appear instantly with no delay.
B. Exit: When triggered by hovering, a tooltip disappears 500 milliseconds after the cursor leaves the element. The same 500 millisecond delay applies when dismissed via keyboard. Tooltips aren’t focusable. On touch devices, the tooltip disappears immediately after the user taps outside the element.

Note: When displaying tooltips in sequence, use a 200 millisecond delay between tooltips. This means the previous tooltip disappears and the new one appears after the delay.

Slow (1-3 seconds)

Components in this category are typically larger or more resource intensive. They include complex data visualizations, transitions that involve multiple components, or major layout changes that need more processing. Some components are designed to stay visible longer, not because they’re slow to respond, but because they provide important information. For example, message toasts use a longer display time on purpose, so users have enough time to read and process the message without interrupting their workflow.

Message toast – example of a slow interaction (3,000 milliseconds default display time)

An example of slow interaction timing is message toast behavior:

Very Slow (more than 3 seconds)

Response delays over 3 seconds can disrupt user flow and may lead to frustration or abandonment if you don’t handle them well. If delays can’t be avoided, provide visual feedback to reassure users. Use elements like content placeholders or progress indicators.

In some cases, time-related components – like message toasts – are meant to remain visible for long periods by design. This helps ensure users have enough time to read and process important information. Longer display times are acceptable when providing informative feedback without interrupting the user workflow.

Busy indicator – example of a slow or very slow interaction (1-3 seconds display time)

Minimum and Maximum Display Times

The recommended minimum display time is 500 milliseconds. This helps prevent flickering. Adjust this duration as needed to fit your specific use case.

If a process takes more than 10 seconds, show a more detailed progress animation, such as a placeholder animation.

An example of very slow interaction timing is the busy indicator: