Case study:
Defining Motion Design Guides.
Bringing motion into the design system as a first-class design primitive.
Overview.
Our product already had motion, but it wasn’t consistently applied.
Individual designers were making animation calls in isolation, developers were hardcoding timing values and there was no shared language between disciplines.
The result was a product that felt subtly incoherent. Similar interactions behaved differently depending on who'd built them and the moments that should have felt considered felt arbitrary instead.
The ask was framed as "adding motion to the design system." But the real problem was deeper. We had no shared model for thinking about motion at all.
No principles, no tokens, no way for a designer and a developer to have a productive conversation about whether a transition was right or wrong. Before I could write a line of documentation, I had to establish that shared foundation.
Company: Toyota Connected Europe
Role: Lead Product Designer
Timeline: Aug 2024
Product: Design System
The Challenge.
My first move was to resist the urge to start designing and instead understand what the team actually needed.
I held conversations with designers across the product and with our front-end engineers. This was done to diagnose where the real friction was.
What I found was a split problem:
-
Designers wanted permission and confidence. They knew motion mattered, but felt unsure about when to use it and how much to use.
-
Engineers wanted precision. They needed specific, implementable values that mapped cleanly to code.
Both groups were trying to do the right thing with no shared reference point. This reframed the work significantly.
The output wasn't going to be a document about motion theory. It needed to be a practical system:
-
tokens the engineering team could adopt directly,
-
principles designers could apply without second-guessing themselves,
-
a vocabulary that lets both sides talk about motion in the same terms.
My Role.
As Lead Product Designer, I was responsible for:
-
scoping and defining the work, reframing a broad brief into a focused system problem,
-
researching industry motion systems and synthesising principles relevant to our product,
-
collaborating with engineering to define and name the motion token architecture,
-
running workshops with the design team to establish what level of guidance they needed,
-
writing and publishing the documentation into the live design system.
I worked closely with designers and front-end engineers to ensure the guidelines were practical, technically grounded and built to be adopted rather than filed away.
Discovery.
Before defining anything, I needed to understand the space properly. I did a thorough review of how leading design systems approach motion.
I looked specifically at:
-
how they categorised motion,
-
the token architecture,
-
any tension between prescription and flexibility.
This wasn't research for its own sake. I was trying to find the patterns that held across systems and understand where they diverged and why.
The strongest systems drew a hard distinction between functional motion (interface behaviour) and expressive motion (brand and delight).
These two types of motion have different rules, different tolerances and different failure modes. Conflating them leads to guidance that's either too rigid for expressive work or too loose for functional consistency.
Every mature system treated accessibility as a constraint, not an afterthought. Building reduced motion support directly into the token architecture rather than bolting it on at the end. That shaped how I thought about our own system from the start.
Building the Token Architecture.
The most important collaboration in this project was with our front-end engineers. I made a deliberate choice to involve them early.
They understood the performance constraints, knew which values were already in the codebase, and could tell me which naming conventions would map cleanly to the implementation.
We worked together to define two token families: duration and easing tokens.
Duration Tokens.
Duration tokens anchor the system's sense of time. The values were chosen based on research into how the human brain perceives animation.
Below 100ms passes unnoticed, above 1 second starts to feel like lag. The five-step scale gives enough range to differentiate micro and macro motion without creating so many options that decisions become arbitrary.
Token | Value | Type |
|---|---|---|
motion.Duration.500 | 500ms | Macro: Large-area movements |
motion.Duration.400 | 400ms | Macro: Page-level transitions |
motion.Duration.300 | 300ms | Macro: Panel and drawer reveals |
motion.Duration.200 | 200ms | Micro: Hover states, fades |
motion.Duration.100 | 100ms | Micro: Instant state feedback |
Easing Tokens.
Easing tokens govern the character of movement. The difference between an animation that feels physical and one that feels mechanical.
Rather than describing easing in abstract terms, I defined each token around its behavioural purpose.
Token: | Behaviour: | Type: |
|---|---|---|
motion.Ease.Linear | Constant | Colour and opacity transitions |
motion.Ease.In.Out | Slow → fast → slow | Moving elements across the screen |
motion.Ease.Out | Fast → slow | Introducing elements from off-screen |
motion.Ease.In | Slow → fast | Removing elements from the screen |
motion.Ease | Slow → fast → slow | Expanding tiles, reordering |
The naming convention was agreed jointly, mirrored in Figma and in code, so designers and developers were always pointing at exactly the same thing.
Defining the Framework.
I decided to structure the entire guidance framework around the distinction between functional and expressive motion.
Functional Motion.
Functional motion is the interface working as it should. Hover states, dropdown draws, accordions, overlays, menu transitions. It needs to feel natural and predictable.
Users should never consciously notice it, but they'd notice its absence. The governing principle here is that there should always be a 1:1 relationship between what the user does and how the screen responds.
Functional motion reduces friction. When it doesn't, it's failing.
Expressive Motion.
Expressive motion is where brand personality lives. Logo animations, illustrated characters, success and failure states and icon animations.
Used with restraint, these are the moments that make a product feel considered rather than functional.
The risk here is overreach. Expressive motion that draws too much attention, runs too long, or can't be switched off for users who need reduced motion undermines everything it's trying to achieve.
Separating these two categories gave the team a clearer mental model for decision-making.
I distilled this into a set of checklists that designers could use to audit their own motion decisions before moving to handoff. Keeping it deliberately lightweight, designed to prompt thinking rather than replace it.
Designing the Documentation.
I made a conscious effort to write guidance that was specific and honest about where judgment was required.
The Figma documentation covered the full framework:
-
motion principles,
-
token reference with visual examples of each easing curve and duration,
-
implementation notes for engineers (performance considerations, will-change, maintaining 60fps),
-
a clear section on accessibility.
It also included the prefers-reduced-motion media query and the non-negotiable requirement that every animated state has a static equivalent.
The do's and don'ts were written last and deliberately kept tight. The aim was to reduce cognitive load at the point of decision. A short, clear list that a designer could check before handoff.
The Figma file was shared across design and engineering at the same time, which mattered. Motion guidance that only designers have seen doesn't make it into the product.
Impact.
The token architecture gave the engineering team something they could adopt immediately. Specific values with clear naming conventions that removed the guesswork from implementation.
Designers had a framework that distinguished between the places where they should follow the system and the places where they had latitude to make considered creative choices.
But the most meaningful outcome was harder to measure: it changed how the team talked about motion. Before, conversations about animation were imprecise. People were describing what they wanted without a shared vocabulary to do it accurately.
After, designers and developers could point to specific tokens, reference the principles, and have productive disagreements rather than circular ones.
Motion went from being a gap in the system to being a first-class layer of it.