How we think about motion on the web

The tools are mature, the browsers are capable, and most development teams can put something on the screen that moves. What's more difficult is making sure it moves for a reason, and that every animated moment on a site is working together rather than competing. This is how we think about it, and how we work with design teams to get there.

The first question we ask about any animation isn't "can we build this?" It's "does this feel like the brand?"

A luxury brand moves differently to a fintech. A creative studio moves differently to a healthcare company. That distinction should run through every transition, every scroll behaviour, every hover state. When it does, motion stops being decoration and starts doing the same work as the typography or the colour palette.

We've built sites where the right approach is something custom and expressive: scroll-driven sequences, WebGL environments, complex timelines that choreograph an entire page. We've built others where the motion is barely perceptible, and that restraint is exactly right.

A single eased opacity change, a subtle transform on hover. Nothing that calls attention to itself, everything that makes the experience feel considered. The mistake isn't choosing one over the other. The mistake is making that choice without asking whether it fits.

Every project starts differently, and the collaboration looks different each time. Sometimes a design studio comes to us with motion fully considered: references, principles, specific interactions they want to achieve. In those cases our job is to be a skilled and faithful interpreter. To understand the intent precisely, ask the right questions, and find the best technical path to realise it without compromise. We're not there to add our own ideas on top of someone else's vision.

Other times, motion isn't defined beyond a general direction or feeling. The brand has energy but no one has worked out yet what that means in the browser. That's a different kind of conversation, and one we enjoy. We'll share references, propose approaches, prototype early. We might build three versions of the same interaction to see which one lands. That back and forth, done well, usually produces better work than either side would have arrived at alone. Sometimes it's somewhere in between: broad strokes from the design team and room to develop the detail together.

We try to read which mode a project calls for rather than assuming. The goal is always to feel like an extension of the design team, not a separate layer working in parallel. What doesn't change, regardless of who's leading on motion, is that we're thinking about it as a system. Not a collection of individual animations, but a set of behaviours that need to work together.

If there's one thing we see go wrong more consistently than anything else, it's sequencing. A page loads. The heading fades in. Then the subheading. Then an image. Then a card. Then another. By the third staggered element, you've stopped reading and started waiting. The motion has become noise.

Individual animations are easy to approve in isolation. A smooth entrance on a card looks fine when you're looking at just the card. The problem only becomes visible when you see the whole page move at once, and everything is competing for attention rather than working together. Good motion has a logic to it. Elements move as a group, or in a deliberate sequence that means something. The eye is led somewhere. There's a hierarchy. The animation is doing editorial work, not just announcing its own presence.

We think about this at a system level before we start building. What moves first, what follows, what stays still, and why. When that conversation happens alongside the design rather than after the handover, the result is almost always better.

We work across the full range of motion tooling, and the choice matters.

CSS is where we start by default. Transitions, transforms, keyframe animations. Fast, hardware-accelerated, no JavaScript overhead. For most subtle UI motion it's the right tool, and reaching for anything heavier is usually over-engineering.

Framer Motion is our go-to for React-based projects where interactions are tied to component state. Gesture handling, layout animations, presence transitions. It keeps motion close to the component logic, which makes it easier to maintain over time.

GSAP is where we go for timeline-based work. Complex scroll sequences, multi-element choreography, anything that needs precise control over timing and easing across a large number of moving parts. It's the most powerful option and the one that requires the most considered approach.

Rive and Lottie handle vector animation. Rive in particular is worth calling out: it allows for interactive, state-driven animation that would be impractical to build in code. It's increasingly the right answer for animated illustration and icon work, and something we've been using more as the tooling has matured.

WebGL and Three.js are for when the brief genuinely calls for a three-dimensional or generative environment. These add real complexity and real build time. When they're the right call, they can do things nothing else can. When they're not, they're expensive for the sake of it.

The tool should follow the brief. We've seen plenty of sites that reached for WebGL when CSS would have done the job better, and plenty that held back from GSAP when a proper timeline would have solved a problem cleanly.

Motion is one of the fastest ways to make a site feel broken. A dropped frame, a janky scroll, a transition that stutters on a mid-range device: these things register immediately, even to a user who couldn't articulate why the site felt off.

Performance is built into how we think about motion from the start, not reviewed at the end. That means being deliberate about which properties we animate, being careful about how much is running simultaneously, and testing on real devices rather than a development machine.

This is also where restraint often wins. A site with fewer, well-executed animations will always feel faster and more intentional than a site with more motion that's working against the browser.

When we start a project, motion isn't an afterthought and it isn't a list of interactions to tick off. It's a question about the brand, the experience, and what the site should feel like to move through.

The best results come when that conversation starts early, when there's still room to shape the approach together. If you're working on something where motion is going to do real work, it's worth bringing us into that conversation before the design is locked. Not because we need to take over, but because the earlier we understand the intent, the better we can serve it.