Micro Interactions Examples: A Bank Card You Shatter to Unfreeze

A card freeze you can see, hear and shatter. How the Payno build works under the hood, and what these micro interactions examples teach product designers.

Written by
Ayoub Kada
Published on
October 22, 2026
Read time
7 min
Category

The best micro interactions examples make a state change impossible to miss. In Payno, one of my AI experiments, freezing your bank card covers it in frost, and unfreezing it means tapping the ice three times until it cracks and shatters, with sound. It is a playful build, but the lesson is serious: a micro interaction should make the user feel the consequence of what they just did. Below I break down how the effect really works in the browser (alpha video, a canvas crack engine, panned audio, springy motion), and what product designers can reuse in a real fintech app.

What Payno is, and why a freeze button deserves this much care

Payno is a concept bank card app. You can open it live on the Payno experiment page; it is one of the playable builds in my AI design experiments. The home screen has a balance you can hide, four action tiles, your card in a sleeve and a list of recent transactions. Tap the card and you land on Manage Card, with three tiles: Freeze, Limit and Show.

Most banking apps treat "freeze card" as a toggle. A switch slides, a label changes from Active to Frozen, done. Functionally that is fine. Emotionally it is weak, and that matters more than it sounds. People freeze a card when something feels wrong: a lost wallet, a strange charge, a card left in a taxi. They want to be sure it worked. A tiny switch in a settings list does not give that certainty.

So the idea behind Payno is literal. Freezing the card freezes it. Frost grows over the card, and the frozen state is visible from across the room. Unfreezing asks for a small, deliberate effort: three taps on the ice, each one cracking it further, until it breaks apart.

How the shatter-to-unfreeze micro interaction works under the hood

I read the live build's source to describe this accurately. It is a web build (HTML, CSS and JavaScript) that recreates a native iOS feel; the experiment item lists Figma, Claude, the Figma MCP, SwiftUI, alpha video and physics as the tools behind it. Four layers do the work.

Layer 1: frost as a transparent video

The frost is not drawn in code. It is a video with transparency laid over the card. The build ships two versions of the same clip: a QuickTime file (the HEVC with alpha format Safari supports) and a WebM for other browsers, plus a still frost image for the resting frozen state. Separate freeze and thaw clips play depending on the direction. Video is the right tool here: frost is organic texture that would be expensive to simulate and easy to make look fake.

Layer 2: a canvas engine for cracks and shards

The cracks are code. A dedicated script draws on a canvas over the card, with functions to make a crack, draw it, draw specks, glints and dust, and then break the ice into pieces. It uses radial and linear gradients, blur filters and seeded randomness, so each crack looks different but stays controlled. Each tap adds damage. The third tap triggers the shatter: shards fly, fade and spin away, and the card underneath is live again.

Layer 3: sound that comes from where you tapped

This is the part people notice without knowing why. The build loads short sound files through the Web Audio API: tap sounds, two levels of ice cracking, and a shatter. Several come in left, center and right variants, and the code creates a stereo panner, so a crack on the left of the card sounds like it is on the left. There is a sound toggle in the corner, because sound in an interface must always be optional.

Layer 4: motion that behaves like a physical object

The CSS uses overshooting cubic-bezier curves for the press and pop states, which is what gives buttons that slight spring. The card also reads device orientation, with a permission request on iOS, so the card can lean and catch a sheen as you tilt the phone. On devices that support it, the build calls the vibration API for a small physical tap. Every press element scales down slightly on touch, so the whole app feels pressable, not just the hero moment.

Micro interactions examples from the same build, ranked by usefulness

The shatter gets the attention, but Payno has several smaller interactions that are easier to bring into a real product. Here is how I would rate them for a production banking app.

InteractionWhat it doesShip it in a real app?Why
Frost on freezeVisible frozen state on the card itselfYesMakes a safety state obvious at a glance, which is the actual user need
Three taps to unfreezeAdds deliberate effort to reactivationMaybeGood friction for a security action, but needs an accessible alternative
Hide balanceSwaps the amount for dots with an eye iconYesUseful in public places, cheap to build
Copy card detailsCopy buttons with a check icon swapYesClear confirmation that the copy worked
Spending bar fillAnimates spend against a monthly limitYesMotion draws the eye to the one number that matters
Positional crack soundStereo panned audio per tapRarelyDelightful, but most users bank with sound off
Tilt sheen on the cardCard leans with device orientationRarelyNeeds a permission prompt, which is a bad trade for decoration

Notice the pattern. The interactions worth shipping are the ones that confirm something the user cares about: is my card safe, did my copy work, how much have I spent. The ones I would hold back are the ones that ask the user for something (a permission, sound on) in return for pure delight.

What micro interactions examples like this teach product designers

My working rule is the same one I used on onboarding at ViewStats: show value first, ask for trust second. I wrote up that use case in onboarding UX best practices from a 13% to 65% activation fix. Micro interactions follow a smaller version of it. Give feedback first, add personality second.

Three things I take from Payno into real work.

Match the drama to the stakes. A like button can bounce. A card freeze can take over the card. A transfer confirmation should be calm and certain. The size of the animation should track how much the user is worried about the outcome, not how proud the team is of the effect.

Friction can be a feature. Product teams are trained to remove steps. But reactivating a frozen card is a security action, and three taps on ice is a tiny, pleasant speed bump that prevents an accidental unfreeze. The trick is that the friction is fun, so it never feels like a punishment.

Pick the cheapest tool per layer. Video for organic texture, canvas for things that react to input, CSS for springy UI, Web Audio for sound. Trying to do everything in one technique is how micro interactions become heavy and fragile.

There are limits. This kind of interaction costs real build time, it needs a reduced motion path, and the three-tap pattern needs a plain button alternative for people using screen readers or switch control. In a regulated banking app, legal and accessibility reviews will rightly push back on anything that hides a state behind an effect. I would ship the frost and the clear frozen label together, never the frost alone.

Why a design engineer builds this instead of handing it off

A spec for this interaction would be painful to write. "Ice cracks a bit more on each tap, sounds a little to the left if you tap left, then shatters satisfyingly" does not survive a handoff. The feel lives in timing curves, crack randomness and sound levels, and those only get right by playing with the real thing.

That is why my role moved toward design engineering. On ViewStats, the creator platform from the team behind MrBeast, I worked in the codebase with Cursor, Claude Code, React and TypeScript, built components and opened pull requests; the details are in the ViewStats creator tools case study. The experiments push that further: design in Figma, use Claude and the Figma MCP to get from design to working code, then tune the motion and sound by hand. If you want the broader view of the role, start with what a product designer does.

FAQ about micro interactions

What are micro interactions in UI design?

Micro interactions are small, single-purpose moments in an interface: a button press, a toggle, a copy confirmation, a pull to refresh. Each one has a trigger, a response and feedback. Good ones confirm what happened and make the product feel responsive. Freezing a card in Payno is one micro interaction with a very visible response.

What are good micro interactions examples for a fintech app?

Hiding and revealing the balance, a clear frozen card state, copy confirmations on card details, an animated spending bar against a limit, and calm success states after a transfer. In fintech, prioritise interactions that build certainty about money and security over ones that are only decorative.

How do you build micro interactions, in Figma or in code?

Sketch and time them in Figma or a prototyping tool, but tune them in code. Easing, randomness, sound and haptics only feel right on a real device. That is the main argument for designers who can ship code, or at least work closely with an engineer at the keyboard.

Are micro interactions bad for accessibility?

They do not have to be. Respect reduced motion settings, never use animation or sound as the only signal of a state, keep sound optional, and offer a plain control next to any gesture-based action like tapping ice three times.

Try it, then steal the pattern

Open Payno on your phone, freeze the card, and shatter the ice with sound on. Then look at your own product and find the one state change your users worry about most. That is where your next micro interaction belongs.

If you are building a fintech or consumer app and want interactions that feel this alive without hurting clarity, work with me as your product designer.

If you have a web or mobile app idea in mind or you need some advice about product design, feel free to get in touch ✉️