Micro-interaction design covers the small, purposeful responses a product gives to user actions – a button state that confirms a click landed, a loading indicator that communicates progress, an error state that explains what went wrong without alarming the user. In isolation each one feels minor. Collectively they determine whether a product feels responsive and trustworthy or flat and unreliable.

A UX agency typically focuses on flows, information architecture, and usability. An interaction design agency works on the behaviour layer – how screens transition, how elements respond to input, how motion communicates state changes. The two disciplines overlap but the deliverables are different: interaction design ends with motion specs, animation assets, and developer handoff kits, not wireframes.

AI features introduce interaction states that traditional motion design doesn't cover – streamed text responses, agent thinking states, uncertain or async outputs, and multi-step processing. We design loading states, response animations, and feedback patterns that tell users what the AI is doing at every moment. The goal is to make AI behaviour feel intentional rather than unpredictable.

Motion design covers the broader movement language of a product – how screens enter and exit, how data visualisations animate, how the product transitions between major states. Micro-interaction design focuses on smaller, functional moments – the feedback a toggle gives when it switches, the way a form field responds to an error, the confirmation a submission receives. Most products need both, and they need to follow the same principles to feel coherent.

The audit runs over one week. We review your existing flows, map every point where motion or feedback states are missing or inconsistent, and identify the gaps between what your prototypes specify and what your developers receive. The output is a motion friction map, a feedback state audit, and a prioritised brief your team can act on immediately – with or without continuing to a BUILD engagement.

Yes – and we prefer it. Adding a motion layer to an existing system is more useful than building one in isolation. We work inside your Figma files, align with your component structure, and deliver animation specs and Lottie assets that fit what your developers already use. The goal is a motion system that your team can maintain and extend, not one that requires us to be present for every future decision.

Prototype-to-motion handoff is one of the most common places motion intent gets lost. We deliver Lottie files, CSS animation specs, and interaction notes written for your stack – not generic exports that leave developers guessing. Every pattern includes an interactive prototype so developers can see the intended behaviour before they build it.

Motion hurts more than it helps when it draws attention to itself, slows users down, conflicts with accessibility needs, or exists without a clear functional purpose. We cover this in detail in our guide on the five contexts where animation is the wrong call – and it's something we address explicitly in every audit we run.