One link. No brief. A motion system that didn't exist, now used across design and code in production.
Role:
UX Designer
Company:
Computershare
Scope:
Global Design System contribution
The brief was a single sentence: look at Material Design and see if you can make motion work. No scope, no precedent, no existing practice to build from. The design system had foundations for colour, typography, spacing, and components — but motion as a designed, documented, and systematised practice simply didn't exist.
The real problem was more fundamental than missing tokens. Designers work in cubic bezier curves and durations. Engineers work in physics-based springs: stiffness, damping, mass. These two models produce identical-looking motion through incompatible specifications. There was no shared language, no handover convention, and no way for a designer and engineer to reference the same animation and mean the same thing.
The question I kept coming back to was simple: how do I stop rebuilding the same things and start reusing them?
Defining the gap. High level landscape of potential users.
The token taxonomy decision tree, the three-step selection hierarchy.
Research into Material Design's motion system provided the structural model: categorise motion by intent (standard vs expressive) and separate spatial motion from effects motion. That taxonomy became the skeleton for Computershare.
The real problem was more fundamental than missing tokens. Designers work in cubic bezier curves and durations. Engineers work in physics-based springs: stiffness, damping, mass. These two models produce identical-looking motion through incompatible specifications. There was no shared language, no handover convention, and no way for a designer and engineer to reference the same animation and mean the same thing.
The question I kept coming back to was simple: how do I stop rebuilding the same things and start reusing them?
The starting point was research: pull apart how Material Design structures motion, understand what tokens actually exist in the CPU design system, and identify what a complete motion system would need to contain.
Bezier curves over springs. Not all Computershare products are built in React. A spring-based implementation is React-specific. Bezier curves with explicit duration values work in any environment. This was the constraint that determined everything downstream.
A three-step decision framework. Rather than publishing a flat token table, the system is structured as three sequential questions: standard or expressive, spatial or effects, fast or default or slow. The decision arrives at the token. This maps the mental model users have when choosing motion, not the taxonomy the system happens to contain.
Token naming as shared vocabulary. Token names were designed to be identical in Figma and code. A designer and an engineer referencing standard.spatial.default are describing the same motion regardless of which tool they're in.
The token taxonomy decision tree, the three-step selection hierarchy.
The Figma variable architecture — primitive duration values mapped to semantic tokens following the standard and expressive, spatial and effects, fast and default and slow hierarchy. Defined in Token Studio in collaboration with the engineer, establishing the shared source of truth for both implementations.
The component library covers the recurring surface area of lead generation and ecommerce builds: buttons across all variants and states, forms including inputs, checkboxes, radio buttons, and field layouts, navigation with header, footer, mega menu, and dropdown patterns, tiles in multiple layout configurations, and pagination.
The Zeroheight documentation — Getting Started using the three-step framework, a motion tokens reference table, a Design tab with Figma implementation instructions, and a Code tab with a file structure guide for engineers. Each layer speaks to a different audience using the same token names as connective tissue.
The GDS Variables/tokens board showing the primitive value flowing to the semantic variable.
The GDS Variables/tokens board showing the primitive value flowing to the semantic variable.
The code implementation carried out by the engineer building from the token architecture. Three files: theme.ts for raw token values, motionConfig.ts mapping tokens into readable categories, MotionExample.tsx demonstrating usage. The naming directly reflects the taxonomy from the design phase.
The Code tab in Zeroheight showing the file structure and step-by-step guide.
The Figma implementation instructions were tested with in-house designers in Melbourne graduate to senior with no walkthrough, no visual aids, just the written steps. Every participant completed the task. The documentation works without hand-holding, which matters because the broader design system team spans Melbourne and the UK and there's no one nearby to fill gaps.
The motion tokens were then applied to production: splash screen and onboarding flows for Investor Centre HK, Investor Center US, and Sphere three products in development simultaneously. Prototype annotations reference token names rather than hardcoded bezier values, which is exactly what the system was designed to produce.
The approach I developed here primitives feeding semantics feeding components, grounded in the technology it needs to serve carried directly into my later work at Computershare, applied at the scale of a regulated, multi-market financial product.
Before: no motion tokens, no shared language between design and code, no guidance for cross-product consistency.
After: a published motion foundation in the global design system, a token structure consumable across all tech stacks, tested documentation for both designers and engineers, and live production use across three regional products simultaneously. The work was validated by the head of the global design system in the UK.
The most durable outcome is the shared vocabulary. Designers and engineers at Computershare can now reference the same token name and mean the same motion, regardless of which tool they're working in.
The most interesting constraint wasn't technical. It was that two incompatible systems needed to feel like one thing to the people using them. The solution wasn't to pick one or explain both it was to create a token layer that sits above both, so the same name is meaningful regardless of what implements it underneath. This is what design systems do at their best: the value is not in the components or the tokens. It's in the shared language.