Motion foundations:
Shared Body Language
( ROLE )
Product Designer
( TEAM )
Gestalt Design Team, Pinterest
( TIMELINE )
2024
( TOOLS )
Figma, Protopie, After Effects
Same interaction, different timing on iOS, Android, and Web. Easing values picked ad hoc. Specs rarely written – engineers built from memory or guesswork. The product moved, but it didn't say anything consistent.
I built Pinterest's motion system from scratch: principles, easing tokens, component specs, adoption playbook. It gave teams a shared language for how the product moves.
Pinterest was going through a major product redesign. Motion had no foundation to build on – no shared principles, no tokens, no specs. Every team made their own calls.
Motion at Pinterest wasn't just inconsistent — it was actively confusing. Transitions glitched. Components behaved unpredictably: a toast appeared from the top of the screen, but you could only dismiss it by swiping left. Everything — every interaction, every state change — had the same duration and the same easing curve, regardless of what was happening or why.
The product moved. It just didn't make sense.
The problem wasn't a lack of animation. It was a lack of structure.
Problem
- Turn motion from “random animations” into shared infrastructure.
- Create brand-consistent motion that scales.
- Make it adoptable in real workflows.
Challenge
[before system implementation]
The key decision
Before touching a single value, I had to figure out what the system was actually trying to do.
Motion at Pinterest serves two jobs that change at different speeds: helping users navigate and understand (UX), and expressing Pinterest's brand personality (visual). I split the principles into two layers – Experience and Visual – so one could stay stable while the other evolved. The system could refresh its look without breaking how it works.
That decision shaped everything that came after.
How it came together
1. Audit
Before defining anything new, I mapped what existed – animations across iOS, Android, and Web. Documented where timing contradicted itself, where motion contradicted brand tone. The audit made the problem concrete: it wasn't random noise, it was structural.
2. Principles
I wrote the motion principles and validated them with the team. The Experience layer defines how motion supports users – clarity, focus, meaningful feedback. Stable by design.
The Visual layer defines brand tone in motion. Built to evolve without destabilizing what's underneath.
3. Easing System
Rather than picking curves case by case, I designed a reusable easing system mapped to interaction types — expressive for elements opening within the user's field of view, enter and exit for most UI transitions, lateral for navigation between surfaces. Each easing is documented with cubic-bezier values, duration ranges, usage logic, and real product examples.
Alongside it I defined a duration scale tied to movement distance and visual weight, plus recommended easing + timing pairings for common patterns.
The values weren't arbitrary. I tuned them around how heavy an element should feel and how close it sits to the user.
Buttons, switches and other small controls are the lightest elements and the closest to the user — bouncy and short. Toasts sit close too, but they carry more mass, so the same bounce plays out over a slightly longer duration — which is also exactly the beat they need to register. Anything covering half the screen or more is the heaviest and sits deepest in the interface: no bounce at all. Heavy things don't spring back, and at that scale a such curve stops reading as delight and starts reading as restlessness.
Where the physical model and the communication goal pointed to the same value, I took that as a signal the system was right.
The underlying model was real-world physics: mass, distance, proximity. If motion obeys rules people already know from the physical world, the interface feels natural instead of animated.
4. Tokens
Validating the system took more prototypes than one person could build, so I split the work with the other motion designer – I defined what each easing and duration pairing needed to prove, and we built our halves in parallel. The validated combinations were then translated into implementable tokens together with engineers. At one point I updated an existing token that was out of sync with the system, because consistency mattered more than leaving things untouched.
Motion Guidelines in Gestalt Library
5. Guidance and playbook
I wrote the content and conceptual framework for the playbook and guidelines – what to use when and why. The goal was that a designer or engineer who'd never thought about motion could pick it up and make a reasonable decision.
In parallel, I introduced a standardized motion spec format, paired with interactive ProtoPie prototypes and mentored teammates on how to create system-aligned motion specs – we began producing component-level motion specs, embedding motion directly into component to reduce improvisation and ensure consistent default behavior.
By the end: motion principles published in Gestalt, easing tokens live, around 15 components with motion specs, and a spec format that teams used on new features going forward.
Before: motion decisions lived in people's heads. Engineers guessed at easing, platforms diverged, every new animation started from scratch.
After: new features shipped using the token system. Component motion had a documented default. Design-to-engineering handoff got clearer.
[Left: before – components have no motion.
Right: system applied.
Duration, easing, and weight aren't guessed –
they're defined.]
Impact
"Adding bespoke motion to our UI components will add another layer of polish. Thank you for your attention to detail and willingness to iterate throughout this process." – Camden Asay, Gestalt Design System Manager
I built a motion foundation other people could actually use: principles → tokens → specs → prototypes.
Instead of shipping isolated animations, we set up a system that makes motion repeatable, consistent, and cheap to implement — and taught teams how to work with it. Motion principles are published in Gestalt, easing tokens are live, around 15 components ship with motion specs, and the spec format is what teams now reach for on new features.
+
→
Before, toast had its own timing logic – or no real logic at all. It appeared from the top, but to dismiss it you'd swipe left. After establishing the system, toast became a reference point. Toolbar inherited the same weight and easing, not by coincidence but because both now pull from the same foundation. That's what a system does: one decision works across surfaces.
[Animations for the Automagical Boards initiative, built following the motion system]
The system made cross-team work faster.
Kirill Margolin, who managed the Automagical Boards team, put it this way:
"Whenever our team had any motion-related requests, Lesia was my go-to designer. She's someone I could fully rely on to deliver work that was well-crafted, fast, and ready to hand off to development."
Also, the system became the foundation the Celebration System was built on. That work was UXR-validated: confetti perceived as more purposeful +37% vs. baseline.
What I'd do differently
Custom easings dated faster than expected. Springs became the default on both iOS and Material Design – if I were starting today, I'd work with what the platforms already offer rather than defining values from scratch. Better investment: clear guidance on choosing the right spring for the right context.
I'd also focus earlier on components. Built-in motion at the component level propagates quietly – other designers rarely touch it, which means if it's right, it just works. That, combined with transition documentation written earlier in the process, would have had more lasting impact than the principles layer alone.
other projects
Motion foundations:
Shared Body Language
( ROLE )
Product Designer
( TEAM )
Gestalt Design Team, Pinterest
( TIMELINE )
2024
( TOOLS )
Figma, Protopie, After Effects
Same interaction, different timing on iOS, Android, and Web. Easing values picked ad hoc. Specs rarely written – engineers built from memory or guesswork. The product moved, but it didn't say anything consistent.
I built Pinterest's motion system from scratch: principles, easing tokens, component specs, adoption playbook. It gave teams a shared language for how the product moves.
Pinterest was going through a major product redesign. Motion had no foundation to build on – no shared principles, no tokens, no specs. Every team made their own calls.
Problem
Challenge
Motion at Pinterest wasn't just inconsistent — it was actively confusing. Transitions glitched. Components behaved unpredictably: a toast appeared from the top of the screen, but you could only dismiss it by swiping left. Everything — every interaction, every state change — had the same duration and the same easing curve, regardless of what was happening or why.
The product moved. It just didn't make sense.
The problem wasn't a lack of animation. It was a lack of structure.
- Turn motion from “random animations” into shared infrastructure.
- Create brand-consistent motion that scales.
- Make it adoptable in real workflows.
[before system implementation]
The key decision
Before touching a single value, I had to figure out what the system was actually trying to do.
Motion at Pinterest serves two jobs that change at different speeds: helping users navigate and understand (UX), and expressing Pinterest's brand personality (visual). I split the principles into two layers – Experience and Visual – so one could stay stable while the other evolved. The system could refresh its look without breaking how it works.
That decision shaped everything that came after.
How it came together
1. Audit
Before defining anything new, I mapped what existed – animations across iOS, Android, and Web. Documented where timing contradicted itself, where motion contradicted brand tone. The audit made the problem concrete: it wasn't random noise, it was structural.
2. Principles
I wrote the motion principles and validated them with the team. The Experience layer defines how motion supports users – clarity, focus, meaningful feedback. Stable by design.
The Visual layer defines brand tone in motion. Built to evolve without destabilizing what's underneath.
3. Easing System
Rather than picking curves case by case, I designed a reusable easing system mapped to interaction types — expressive for elements opening within the user's field of view, enter and exit for most UI transitions, lateral for navigation between surfaces. Each easing is documented with cubic-bezier values, duration ranges, usage logic, and real product examples.
Alongside it I defined a duration scale tied to movement distance and visual weight, plus recommended easing + timing pairings for common patterns.
The values weren't arbitrary. I tuned them around how heavy an element should feel and how close it sits to the user.
Buttons, switches and other small controls are the lightest elements and the closest to the user — bouncy and short. Toasts sit close too, but they carry more mass, so the same bounce plays out over a slightly longer duration — which is also exactly the beat they need to register. Anything covering half the screen or more is the heaviest and sits deepest in the interface: no bounce at all. Heavy things don't spring back, and at that scale a such curve stops reading as delight and starts reading as restlessness.
Where the physical model and the communication goal pointed to the same value, I took that as a signal the system was right.
The underlying model was real-world physics: mass, distance, proximity. If motion obeys rules people already know from the physical world, the interface feels natural instead of animated.
4. Tokens
Validating the system took more prototypes than one person could build, so I split the work with the other motion designer – I defined what each easing and duration pairing needed to prove, and we built our halves in parallel. The validated combinations were then translated into implementable tokens together with engineers. At one point I updated an existing token that was out of sync with the system, because consistency mattered more than leaving things untouched.
[Motion Guidelines in Gestalt Library]
5. Guidance and playbook
I wrote the content and conceptual framework for the playbook and guidelines – what to use when and why. The goal was that a designer or engineer who'd never thought about motion could pick it up and make a reasonable decision.
In parallel, I introduced a standardized motion spec format, paired with interactive ProtoPie prototypes and mentored teammates on how to create system-aligned motion specs – we began producing component-level motion specs, embedding motion directly into component to reduce improvisation and ensure consistent default behavior.
By the end: motion principles published in Gestalt, easing tokens live, around 15 components with motion specs, and a spec format that teams used on new features going forward.
Before: motion decisions lived in people's heads. Engineers guessed at easing, platforms diverged, every new animation started from scratch.
After: new features shipped using the token system. Component motion had a documented default. Design-to-engineering handoff got clearer.
Impact
[Left: before – components have no motion. Right: system applied.
Duration, easing, and weight aren't guessed – they're defined.]
"Adding bespoke motion to our UI components will add another layer of polish. Thank you for your attention to detail and willingness to iterate throughout this process." – Camden Asay, Gestalt Design System Manager
I built a motion foundation other people could actually use: principles → tokens → specs → prototypes.
Instead of shipping isolated animations, we set up a system that makes motion repeatable, consistent, and cheap to implement — and taught teams how to work with it. Motion principles are published in Gestalt, easing tokens are live, around 15 components ship with motion specs, and the spec format is what teams now reach for on new features.
→
+
Before, toast had its own timing logic – or no real logic at all. It appeared from the top, but to dismiss it you'd swipe left. After establishing the system, toast became a reference point. Toolbar inherited the same weight and easing, not by coincidence but because both now pull from the same foundation. That's what a system does: one decision works across surfaces.
[Animations for the Automagical Boards initiative, built following the motion system]
The system made cross-team work faster.
Kirill Margolin, who managed the Automagical Boards team, put it this way:
"Whenever our team had any motion-related requests, Lesia was my go-to designer. She's someone I could fully rely on to deliver work that was well-crafted, fast, and ready to hand off to development."
Also, the system became the foundation the Celebration System was built on. That work was UXR-validated: confetti perceived as more purposeful +37% vs. baseline.
What I'd do differently
Custom easings dated faster than expected. Springs became the default on both iOS and Material Design – if I were starting today, I'd work with what the platforms already offer rather than defining values from scratch. Better investment: clear guidance on choosing the right spring for the right context.
I'd also focus earlier on components. Built-in motion at the component level propagates quietly – other designers rarely touch it, which means if it's right, it just works. That, combined with transition documentation written earlier in the process, would have had more lasting impact than the principles layer alone.
other projects
Motion foundations:
Shared Body Language
( ROLE )
Product Designer
( TEAM )
Gestalt Design Team, Pinterest
( TIMELINE )
2024
( TOOLS )
Figma, Protopie, After Effects
Same interaction, different timing on iOS, Android, and Web. Easing values picked ad hoc. Specs rarely written – engineers built from memory or guesswork. The product moved, but it didn't say anything consistent.
I built Pinterest's motion system from scratch: principles, easing tokens, component specs, adoption playbook. It gave teams a shared language for how the product moves.
Pinterest was going through a major product redesign. Motion had no foundation to build on – no shared principles, no tokens, no specs. Every team made their own calls.
Motion at Pinterest wasn't just inconsistent — it was actively confusing. Transitions glitched. Components behaved unpredictably: a toast appeared from the top of the screen, but you could only dismiss it by swiping left. Everything — every interaction, every state change — had the same duration and the same easing curve, regardless of what was happening or why.
The product moved. It just didn't make sense.
The problem wasn't a lack of animation. It was a lack of structure.
- Turn motion from “random animations” into shared infrastructure.
- Create brand-consistent motion that scales.
- Make it adoptable in real workflows.
Problem
Challenge
[before system implementation]
The key decision
Before touching a single value, I had to figure out what the system was actually trying to do.
Motion at Pinterest serves two jobs that change at different speeds: helping users navigate and understand (UX), and expressing Pinterest's brand personality (visual). I split the principles into two layers – Experience and Visual – so one could stay stable while the other evolved. The system could refresh its look without breaking how it works.
That decision shaped everything that came after.
How it came together
1. Audit
Before defining anything new, I mapped what existed – animations across iOS, Android, and Web. Documented where timing contradicted itself, where motion contradicted brand tone. The audit made the problem concrete: it wasn't random noise, it was structural.
2. Principles
I wrote the motion principles and validated them with the team. The Experience layer defines how motion supports users – clarity, focus, meaningful feedback. Stable by design.
The Visual layer defines brand tone in motion. Built to evolve without destabilizing what's underneath.
3. Easing System
Rather than picking curves case by case, I designed a reusable easing system mapped to interaction types — expressive for elements opening within the user's field of view, enter and exit for most UI transitions, lateral for navigation between surfaces. Each easing is documented with cubic-bezier values, duration ranges, usage logic, and real product examples.
Alongside it I defined a duration scale tied to movement distance and visual weight, plus recommended easing + timing pairings for common patterns.
The values weren't arbitrary. I tuned them around how heavy an element should feel and how close it sits to the user.
Buttons, switches and other small controls are the lightest elements and the closest to the user — bouncy and short. Toasts sit close too, but they carry more mass, so the same bounce plays out over a slightly longer duration — which is also exactly the beat they need to register. Anything covering half the screen or more is the heaviest and sits deepest in the interface: no bounce at all. Heavy things don't spring back, and at that scale a such curve stops reading as delight and starts reading as restlessness.
Where the physical model and the communication goal pointed to the same value, I took that as a signal the system was right.
The underlying model was real-world physics: mass, distance, proximity. If motion obeys rules people already know from the physical world, the interface feels natural instead of animated.
4. Tokens
Validating the system took more prototypes than one person could build, so I split the work with the other motion designer – I defined what each easing and duration pairing needed to prove, and we built our halves in parallel. The validated combinations were then translated into implementable tokens together with engineers. At one point I updated an existing token that was out of sync with the system, because consistency mattered more than leaving things untouched.
[Motion Guidelines in Gestalt Library]
5. Guidance and playbook
I wrote the content and conceptual framework for the playbook and guidelines – what to use when and why. The goal was that a designer or engineer who'd never thought about motion could pick it up and make a reasonable decision.
In parallel, I introduced a standardized motion spec format, paired with interactive ProtoPie prototypes and mentored teammates on how to create system-aligned motion specs – we began producing component-level motion specs, embedding motion directly into component to reduce improvisation and ensure consistent default behavior.
By the end: motion principles published in Gestalt, easing tokens live, around 15 components with motion specs, and a spec format that teams used on new features going forward.
Impact
Before: motion decisions lived in people's heads. Engineers guessed at easing, platforms diverged, every new animation started from scratch.
After: new features shipped using the token system. Component motion had a documented default. Design-to-engineering handoff got clearer.
[Left: before – components have no motion. Right: system applied.
Duration, easing, and weight aren't guessed – they're defined.]
"Adding bespoke motion to our UI components will add another layer of polish. Thank you for your attention to detail and willingness to iterate throughout this process." – Camden Asay, Gestalt Design System Manager
I built a motion foundation other people could actually use: principles → tokens → specs → prototypes.
Instead of shipping isolated animations, we set up a system that makes motion repeatable, consistent, and cheap to implement — and taught teams how to work with it. Motion principles are published in Gestalt, easing tokens are live, around 15 components ship with motion specs, and the spec format is what teams now reach for on new features.
+
→
Before, toast had its own timing logic – or no real logic at all. It appeared from the top, but to dismiss it you'd swipe left. After establishing the system, toast became a reference point. Toolbar inherited the same weight and easing, not by coincidence but because both now pull from the same foundation. That's what a system does: one decision works across surfaces.
[Animations for the Automagical Boards initiative, built following the motion system]
The system made cross-team work faster.
Kirill Margolin, who managed the Automagical Boards team, put it this way:
"Whenever our team had any motion-related requests, Lesia was my go-to designer. She's someone I could fully rely on to deliver work that was well-crafted, fast, and ready to hand off to development."
Also, the system became the foundation the Celebration System was built on. That work was UXR-validated: confetti perceived as more purposeful +37% vs. baseline.
What I'd do differently
Custom easings dated faster than expected. Springs became the default on both iOS and Material Design – if I were starting today, I'd work with what the platforms already offer rather than defining values from scratch. Better investment: clear guidance on choosing the right spring for the right context.
I'd also focus earlier on components. Built-in motion at the component level propagates quietly – other designers rarely touch it, which means if it's right, it just works. That, combined with transition documentation written earlier in the process, would have had more lasting impact than the principles layer alone.
other projects
Vochi Text 02 Effect
→
Celebration System
→