What makes a swipe feel like it has weight?

You’re flicking through photos. Each one keeps sliding after your thumb has left, slows, and settles into place. Smooth, I’d call it.

What I mean is that the picture behaved like a thing in the world: something you push keeps going after you stop pushing, and slows gradually rather than all at once. Physicists call the first half momentum and the second half friction. Your hand has known both since you were two.

And the stiff version? In the stiff swipes we see most, the card freezes the instant the finger leaves, then plays a tidy animation to a resting spot on a timer.

Why does that feel cheap when the animation itself is nice? Because the card ignored how fast you were going. A lazy nudge and a hard fling get the same polite glide, and your hand notices even when your mouth can’t say why.

It’s a bowling ball that drops at the foul line and is then carried to the pins by a member of staff. (A polite member of staff. Still.)

How this goes wrong: say the card always takes a third of a second to leave, however it was thrown. Fling it, and it hesitates, as if waiting for permission. Barely touch it, and it rockets off. Neither matches what the hand did, and the hand keeps score.

Scroll to the bottom of a list on an iPhone and keep pulling. The list stretches a little past its end, then springs back when you let go. The first iPhone did this in 2007, and Android added its own stretch at the edges in version 12 (later than you’d think).

Picture the list that stops dead. Your thumb is still moving and the screen isn’t, and you can’t tell whether you’ve reached the end or the app has frozen.

What is the stretch for, then? It answers two questions without a word: you’ve reached the end, and the app is still listening. The wall answers one, badly.

We’d never ship a wall.

That’s the difference between a gutter and a bumper, and it’s the one we care about: a bumper gives a little, says “not that way,” and hands the ball back into play. (The history of ten-pin bowling explains why bumpers exist.)

So how do we build a rubber band out of nothing? Let’s do the sum; it’s short enough to say out loud.

While your finger is inside the allowed range, the panel moves with it, one for one. Past the edge, every extra bit of pull counts for less than the bit before: the first centimeter beyond the end moves the panel about half a centimeter, the fifth only a few millimeters, and by a hand’s width it has all but stopped.

That growing resistance is the whole trick. It’s what a real rubber band does between your fingers: the further it’s stretched, the harder the next bit is. We build it that way every time.

Then you let go, and the panel should return to its edge on a spring, not a timer. I’d insist on that.

What’s the difference? A timer says “get back to the edge in a third of a second, whatever happens.” A spring says “pull toward the edge harder the further away you are, and ease off as you arrive,” which is Hooke’s law from 1660, running inside your phone.

The spring can be interrupted (if your thumb lands again halfway through the return, the panel simply stops under it), and it arrives with a tiny overshoot or none.

The timer can do neither.

How this goes wrong: say the stretch has no resistance, so a list can be dragged a whole screen past its end, then snaps back over a long, fixed second. It reads as a curtain, not a rubber band, and people stop pulling because it feels broken.

This is the part that makes the built-in apps feel like they read your mind.

A flick is a drag plus a speed at the moment of release. The good apps do a small sum with that speed: given how fast the card was moving when you let go, and the friction we’ve chosen, where would it coast to on its own? Then they look at that spot to decide what happens next, not the spot under your finger.

Say a panel has to travel halfway up the screen to count as “open.” You drag it a quarter of the way and let go slowly: it would coast a little, not far enough, so it settles back down. Drag it the same quarter and flick: it would coast past halfway, so it opens.

Same finger position, different intent, different answer!

Roughly, with the kind of slowing-down phones use, double the release speed and the coast is about twice as far. Apple’s designers spent most of an hour on stage on this and its cousins in a talk called Designing Fluid Interfaces. I’d spend the hour.

Back in the alley: nobody scores the shot by where the foul line is. They score it by where the ball ends up.

And one more thing: the animation after the sum should start at the speed the finger left it. If the card was moving at a fair clip and the animation begins from a standstill, there’s a seam: a hitch where the hand stops and the machine takes over. Start from the same speed and the seam disappears.

I think that seam is most of what “cheap” means.

Here’s a moment I’d bet you’ve had this week. You swipe a notification away with a small, quick flick, and it slides back to where it was. So you do it again, harder and longer, and it goes.

By the third notification you’re swiping like you’re trying to push it off the table.

That’s the ball that stops halfway down the lane: nothing happened, and you have to do it all again.

Our rule of thumb: if the person flicked, they meant it. There are two ways for a gesture to say yes. Drag far enough, or flick fast enough.

We never require both.

A long, slow drag is for precision (you want to peek behind the panel without committing), and a short, fast flick is for getting on with it. Both are legitimate ways to bowl, and both should reach the pins!

Isn’t it risky to act on a small flick? A little, I think, and that’s what undo is for on anything you can’t get back. The alternative is worse: a gesture that ignores speed teaches people to exaggerate every swipe, and a person who over-swipes your app quietly believes it’s broken.

They won’t tell you that (nobody does). They’ll just tell you it feels cheap!

So, you, with the panel that slides back: we’d look at the release before anything else.

How this goes wrong: say a card only leaves once it has been dragged past 60% of the screen’s width, whatever the speed. Now try it with one thumb on a large phone: the thumb can’t reach, so the flick fails, the drag fails, and the only thing that works is the small button in the corner. (There should be a button too; we give every gesture a visible twin. It just shouldn’t be the only one that works.)

Pixels weigh nothing, so you have to decide what the thing on screen is pretending to be.

A card in a stack is light: quick to get going, quick to leave, a little bounce on landing is fine. A full-screen panel is heavier: it takes a beat to get moving, and it settles rather than bounces. Think of the rack of balls at the alley: a child’s ball is easy to throw and easy to knock off course; the heavy one carries through.

Where does bounce belong? On things that were thrown, we’d say.

A card flicked off screen can overshoot a touch as it goes, because it had momentum. A button you pressed shouldn’t bounce, because nobody threw it; a press is pressure, so the button can sink slightly under your finger and come back, and that’s all. (A bouncing button is a ball that jumps when you set it down.)

And things with consequences should weigh more. Deleting something is the moment we add friction: a hold instead of a tap.

Weight is a promise about consequence, and the hand believes the promise before the head has read the label.

Every gesture that feels right has three beats, and I think most stiff ones only have the middle one built properly.

Beat one is the touch, where we decide what the gesture is allowed to be: which direction it goes in, and that a card swiped sideways won’t also scroll the list under it. We let the first few millimeters decide the lane and hold it for the rest of the gesture, because a swipe that changes its mind halfway feels like the ball hopping into the next lane.

Beat two is the move, and it has one rule we don’t bend: the thing is under the finger, with no animation between the two.

Beat three is the let-go: the sum and the settle.

Get beat two right and beat three wrong, and the whole thing feels like a video of a swipe rather than a swipe.

How would you find out which of these your screen is missing? Not from the demo; we’d never trust one.

Here’s an afternoon we’d spend, as a hypothetical, on the card and the panel in your question (and you too, reading over their shoulder with a swipe of your own):

1. Flick short and fast, then nudge slow and long. Did both finish the job, and did the fast one look faster?
2. Drag past the edge and hold. Does it give, and does it come back on its own when you let go?
3. Grab it mid-flight: touch a panel while it’s still returning. Does it stop under your finger, or finish its animation and then jump to you?
4. Do all of it with one hand on a big phone, thumb only, standing up.

Apple’s guidance on gestures says most of this in politer language. I wouldn’t expect any screen to pass all four the first time, mine included!

But it’s an afternoon, and it’s the one we’d spend before any other, because it turns “cheap” into “I can’t say why, but it feels right.”

So, you, with the card that leaves politely and the panel that slides back: nothing in your app needs to look different.

What’s wrong is the half-second after the finger lets go, and in that half-second the app is behaving like an alley where the ball stops at the foul line and someone walks it to the pins.

Give the ball its speed. Put bumpers where the walls are. Score the shot by where it would have landed. Let a short flick reach the pins!

Will people say it feels heavier? I doubt it. They’ll say it feels right and not know why, which is what you’re hearing now, in reverse.

In one breath: keep the speed the finger left with, give at the edges instead of stopping, return on a spring rather than a timer, decide by where the thing would have landed, let a short flick finish the job, give heavier things more friction, and lock the lane on the first few millimeters.

That’s all of it. I hope the next person who tries your app flicks a card off the screen without thinking about it, and never notices that they didn’t have to think. (And if you rebuild the let-go, we’d like to see it.)

Hope this helps.