Every project we build includes a baseline set of animations. Not because they were requested, not because we negotiated them into scope — but because we consider them part of what a well-built website looks like. Beyond that baseline, we offer a defined set of additional animations that can be added to any project. The point is the same: a clear menu, agreed in advance, with no guesswork on either side.

This document explains what each animation is, how it behaves, and what it's for. Whether you're a client reviewing what your project will include, or a team member looking for the standard to follow, this is the reference.

The default: included in every project

There is one animation that goes into every website we build, without exception.

Hover response on buttons and links

TYPE: MICROINTERACTION · TRIGGER: CURSOR HOVER

Every interactive element on the site — buttons and text links — has a visual response when the user hovers over it. This is not a decorative choice. It's a functional one: it confirms to the user that the element is clickable.

The rule we follow:

• If the element has a solid color background (a button), the hover changes that color — typically from the primary brand color to the secondary, or to a lighter or darker variant.
• If the element has no background (a text link), the hover adjusts opacity — either reducing it slightly to signal interactivity, or increasing it if the link already has a reduced base opacity.

Transition duration: ~200ms. Smooth enough to feel responsive, not so slow it feels sluggish.

This takes under five minutes per component to implement once the rule is internalized. It costs nothing significant and eliminates the unpolished feel of a site where clickable things don't respond to the cursor.

The menu: available on request

The following animations are not included by default, but they are pre-defined. That means there's no design time, no back-and-forth about how they should behave, and no ambiguity about what you're asking for. Each one is specified below. You pick what applies to your project.

Fade in on scroll

TYPE: ENTRANCE ANIMATION · TRIGGER: ELEMENT ENTERS VIEWPORT

As the user scrolls down, sections and content blocks appear with a fade-in rather than being immediately visible. We use Webflow's native scroll-into-view trigger for this.

How it's applied:

• The primary element in each section (usually the heading or intro text block) loads first.
• If elements are arranged in a horizontal row (e.g., three cards or columns), a staggered delay causes them to appear left to right rather than simultaneously.
• If elements are stacked vertically (e.g., a list), they appear sequentially top to bottom with a light delay between each.

A note on context: scroll-triggered fade-ins are common in smaller-brand websites and are often specifically requested by clients. They're less common on large-brand sites with substantial production budgets — which tend to prefer static, immediate layouts. Neither approach is wrong. This one is available, defined, and ready to apply whenever the project calls for it.

Fade in with upward movement on scroll

TYPE: ENTRANCE ANIMATION · TRIGGER: ELEMENT ENTERS VIEWPORT

A variation of the scroll fade-in above. Instead of appearing in place, the element starts slightly below its final position and rises into it as it fades in. The offset is subtle — a matter of pixels, not dramatic displacement.

This adds a sense of depth and directional flow to the scroll experience. It takes slightly more time to configure than a plain fade-in, since the offset needs to be calibrated and tested at different screen sizes.

Fade in / fade out for dropdowns and accordions

TYPE: INTERFACE TRANSITION · TRIGGER: OPEN / CLOSE ACTION

When a component opens or closes — an FAQ accordion, a navigation dropdown, a content tab — the appearance and disappearance should be smooth rather than instant. We apply a fade in on open and a fade out on close, at approximately 200ms.

Implementation depends on how the component is built:

• Native Webflow dropdown: the opacity transition is configured directly in the dropdown settings. Duration set to ~200ms.
• Custom-built dropdown or accordion (using a show/hide interaction with display: none / display: block): a fade in and fade out animation is added explicitly to the interaction, also at ~200ms.
• Tabs: when switching between tabs, the incoming content appears with a fade in instead of snapping into place.

Sticky navbar with scroll-triggered background

TYPE: SCROLL STATE CHANGE · TRIGGER: SCROLL PAST INITIAL VIEWPORT

The navigation bar starts with a transparent background — visually integrated with the hero section — and acquires a solid background once the user begins scrolling. This is applied only when the design includes a transparent-top navbar, and when the client requests it or the layout clearly calls for it.

Why we work this way

Animation decisions, left open, become a source of friction. The designer doesn't know what to specify. The developer doesn't know what to build. The client doesn't know what to expect. Everyone ends up in a conversation that didn't need to happen.

Defining a menu solves this at every level:

• The development team doesn't have to guess or ask — they follow a known spec.
• The project manager writes less, explains less, and reviews faster.
• The client gets a clear picture of what's included and what's optional, before work begins.

The goal isn't to constrain what's possible — it's to make the standard things effortless, so the creative energy goes where it actually matters.

atQuo is a creative partner that operates at the intersection of design, technology, and marketing strategy. Our **Insights and Talks** exist to demystify this intersection, sharing the expert knowledge required to make smarter decisions about the tools and tactics that drive growth. This same expertise fuels our services, where we execute on that strategy to build powerful digital experiences that help brands scale with clarity and confidence.