Context
Multiple product teams were designing flows in parallel with no shared source of truth for interaction patterns. The result: similar problems solved in slightly different ways across the product.
The Experience Playbook was created to:
- Document micro‑interactions for common flows.
- Encode a motion language that could be reused.
- Provide a single reference for product, design, and engineering.
Structure of the library
Each pattern in the Playbook follows the same structure:
- Intent – what problem the pattern solves and where it should be used.
- Anatomy – key UI elements and states, with annotations.
- Motion spec – durations, easing curves, and distances.
- Do / Don’t – concrete examples showing good and bad implementations.
Patterns are grouped into sections:
- Onboarding
- Search & filtering
- Form validation
- Notifications & toasts
- Empty states & loading
Motion guidelines
All motion in the Playbook is defined in a single timing table shared across platforms. Example:
| Token | Duration | Use case |
|---|---|---|
motion.tap | 140ms | Button presses, toggles |
motion.dialog | 220ms | Modals, drawers |
motion.pageIn | 320ms | Page transitions, overlays |
motion.feedback | 400ms | Async success / failure cues |
Combined with a small set of easing curves, this keeps interactions feeling intentional and repeatable instead of random.
Output
The final Playbook shipped as:
- A monochrome documentation site built with the same design language as the product.
- Embedded prototypes that demonstrate each pattern.
- Copy‑and‑paste snippets for both design tokens and component usage.
Teams now onboard to the product by reading and using the Playbook, which has reduced design review friction and made new work feel much more cohesive.