Before users click, they hover. That window of time — usually just a few hundred milliseconds — is the only chance the interface has to say: “this thing is interactive.” Hover micromotion is not a decorative effect. It is the language of affordance.

Why hover needs animation

Flat design strips away most traditional visual cues: bevels, gradients, thick borders. Looking at a colored box, the user has no way to tell whether it’s a button or decoration — unless it responds as they move the cursor near it.

Hover animation fills that gap. It answers the question “does this do anything?” before the user has to bet a click to find out.

Three types of feedback and when to use them

Lift — the element rises (2–4px) with a deeper shadow. Use for cards, tiles, and navigable items. Creates the sense of a surface “floating up” to invite a touch.

Fill — a subtle background appears, the color shifts. Use for buttons, menu items, tabs. Marks the hit area and confirms “this is a pressable region.”

Tint — an icon or text changes color, with no change in size or position. Use for icon buttons, links inside paragraphs, secondary actions. The most subtle signal — suitable when you don’t want to disturb the layout.

Choosing the right type for each component

Button

A button needs two states: hover and pressed. Hover signals “pressable,” pressed confirms “being pressed.”

• Hover: a slightly lighter or darker fill (10–15% opacity change)
• Pressed: scale down 3–4% — simulating the physical sensation of being pushed down

Avoid: lifting a button on hover. A button doesn’t “float” — it gets “pressed down.”

Navigable card

A card that leads to another page needs a clearer signal than a button, because its area is larger and the user is less certain.

• Lift 3–4px + a wider shadow: creates a focal point, draws the eye in
• The entire card is the hit area — no need for “Click to view” text if the animation is clear enough

Icon button

Icon buttons usually sit side by side (toolbar, action row). Scaling would push the icon toward its neighbors, causing flicker.

• Use fill only: a background pill appears around the icon
• The icon color shifts to the accent to reinforce focus

Inline link

An inline link shouldn’t pull the eye away from the line of text being read.

• Animating the underline from transparent → visible is enough
• No scale, no lift — those would affect line-height

Timing — two numbers to remember

Hover enter: 120–150ms. It must feel instant. Any slower and the user can’t tell whether the cursor has entered the interactive region.

Hover exit: 180–250ms. Slightly slower than enter. The element “settles down” rather than vanishing abruptly — it feels weighted, not jerky.

Always use ease-out in both directions: fast in, slow settle. This is the most natural easing for an object responding to an applied force.

Intensity — less is enough

Property	Subtle range	Overdone range
Scale up	1.02 – 1.04	> 1.08
Translate Y	2 – 4px	> 6px
Shadow blur	+8 – 16px	> 32px
Opacity change	8 – 15%	> 25%

The rule: if you look at the animation and it’s clearly an animation — it may be overdone. Good hover is when the user feels the interface respond without noticing an animation is running.

Don’t use hover to hide information

An optional tooltip is fine. But if information is necessary for the user to act — a button’s label, an option’s description — don’t hide it behind hover. Mobile users will never see it.

The principle: hover only enhances information that’s already visible. It never replaces information.

Hover doesn’t exist on mobile

Desktop hover and mobile tap are two entirely different interactions. When designing hover states in Figma, always check: if you removed all hover animation, would the component still have clear enough affordance?

If not — the problem is in the default state, not the hover state.

See also: Ease vs Spring, Gesture Feedback Motion.