When we shipped Tiketux Reveal, the experience depended entirely on pacing and transition. Static screens could not communicate how chapters should arrive, hand over, and resolve. So instead of writing a motion spec document, I built the spec: a high-fidelity Framer prototype that engineers could actually play.
Screenshots create guesswork
Handing motion to engineering with screenshots is like describing music with sheet notation to someone who has never heard the song. They get the structure, but not the feel. Timing, easing, and the weight of a transition live in the playing, not the reading.
With the prototype as the primary reference, ambiguous states were resolved against the build, not over messages. Implementation review meant comparing the release against the prototype directly.
What I’d do differently
Next time I would pair the prototype with a short motion token sheet, so timing values become reusable decisions instead of one-off craft. A prototype shows the what; tokens encode the why.
Motion specs written as prose would have produced a different, worse product. Playable prototypes are the spec.