Skip to content
← Back to portfolio

Swipe to pay: an app button animation spec

Project release3 min read
Micro-interactionsAnimationPayment UXPrototype

Why a payment button should be swiped

Payment is an action you must not trigger by accident. A normal button fires on a single tap, which feels too casual for paying 70 euros. So the confirmation became a swipe: drag the arrow from left to right, bail out at any point, and only a full swipe submits. The travel distance itself is the are-you-sure, no extra confirmation dialog needed.

Specifying the animation for engineers

An animation only ships if it is implementable. I annotated the parameters right on the Figma prototype: a 200ms delay before entry, smart animate with ease-in, 800ms per segment, and laid the five states out as a spec sheet: idle with a shimmering arrow hinting the direction, the track filling while swiping, a spring back on early release, a dotted loading run once past the threshold, and a green success lock. Engineers built it frame by frame without guessing a single curve.

Swipe and pay button prototype: five states from idle to swiping, loading and success, beside a large detail of the swipe track
The swipe and pay button: idle, swiping, released, loading and success states, with the annotated Figma prototype on the left.