The details that make a product feel alive.
Motion in UI is not decoration — it's communication. A transition that shows where a new screen came from helps users build a mental model of your product. A loading animation that looks like progress (instead of spinning) makes waits feel shorter. A microinteraction that confirms a save or a delete tells users their action worked. When motion is designed well, it's invisible: users experience a product that feels responsive and confident, not a product full of animations. When it's designed badly — transitions that delay rather than inform, animations that fight the user's intent, motion that draws attention to itself — it's actively harmful. We design motion at the level of intent: what is this motion communicating, and does it do that job efficiently?
What's included
- Microinteraction design (hover, press, toggle, scroll)
- Page & screen transition system
- Loading & skeleton screen animations
- Gesture animation design (swipe, pinch, drag)
- Spring-physics & easing library for developers
- Lottie animation production for complex states
How we deliver
- 1Motion principles document for the product
- 2Microinteraction specifications (Figma + video)
- 3Prototyped transition system (Framer or ProtoPie)
- 4Easing & duration token library for developers
- 5Lottie files for complex animations
- 6Implementation guide for development handoff
Technologies we use
- Figma
- Framer
- ProtoPie
- Principle
- After Effects
- Lottie
- GSAP
- Framer Motion
- CSS animations
Why Origin for Interaction & Motion Design
Motion as communication, not decoration
Every animation we design has a job: communicating spatial relationships, confirming actions, or making waits feel shorter. Motion that doesn't do a job gets removed.
Reduced motion designed as standard — not an afterthought
Every animation we specify has a `prefers-reduced-motion` variant. Accessibility is built into the motion system from day one.
Developer-ready outputs: tokens, Lottie files, and prototypes
We don't describe animations in words and hope for the best. Easing tokens, Lottie JSON, and Framer prototypes give developers exact references — no interpretation required.
Industries we serve
“We knew our app looked polished but felt flat. Origin ran a motion audit, designed a system of microinteractions, and handed our developers Lottie files and token specs. The next App Store review mentioned the UI specifically — in the right way.”
Frequently asked questions
- How do you decide which interactions need motion and which don't?
- Motion earns its place when it communicates something the static design can't: spatial relationships between screens, state changes that need confirmation, progress during a wait, or the physical metaphor that makes an action feel natural. Motion costs attention — users notice it — so it should only be there when it's paying for that attention with information. We audit every proposed animation against this standard.
- What's the difference between a microinteraction and an animation?
- A microinteraction is a tiny feedback loop: the moment a button depresses when you press it, the sound or haptic when a toggle switches, the check that appears when a message is sent. They're functional — their job is to confirm that something happened. An animation is a longer-form motion sequence: a page transition, an onboarding illustration, a loading state. Both are part of what makes a product feel alive, but they serve different purposes and are designed at different levels of detail.
- How do you handle reduced motion accessibility?
- We design all motion with a `prefers-reduced-motion` variant as standard. The reduced-motion version communicates the same information — a state change, a transition, a confirmation — using opacity, colour, or instantaneous changes rather than movement. We specify both variants in the design documentation and implementation guide. Accessibility is not an optional add-on to motion design.
- Can you produce the motion assets developers need — not just design files?
- Yes. For simple microinteractions, we provide specifications with timing curves, duration values, and easing functions formatted as design tokens that map directly to CSS or Framer Motion. For complex animations, we produce Lottie JSON files directly from After Effects. For prototype-quality transitions, we build them in Framer or ProtoPie and share the prototype alongside the spec. Developers should never have to guess at 'make it feel springy'.
- Our product has no motion at all — where do we start?
- With a motion audit and principles document. We review the product and identify the moments where motion would communicate something meaningful — not everywhere, just the high-value moments. We then write a motion principles document: what does motion mean in your product, what easing curves reflect your brand's personality, what durations feel right for different interaction types. This becomes the system that all future motion is built on, rather than ad-hoc animation added screen by screen.