Cut, don’t dissolve: what shouldn’t animate in an app

Here’s a moment I’d bet you recognize. You tap the menu in an app you use daily, and you’re not looking at the menu; you’re looking at where the third item is going to be, because you’ve tapped it a hundred times. And the menu is still on its way, sliding down, fading up. For a beat, the screen is behind you.

Why does a beat that short grate? Because it’s slower than the person. You’d already decided, and now you’re being shown the deciding, which is exactly what a dissolve feels like when the story wanted a cut.

There’s a number worth knowing here. Google’s guidance on response times puts the limit for something feeling instant at about a tenth of a second (the Nielsen Norman Group has been saying the same thing since the nineties), and a gentle quarter-second fade is more than twice that. Nobody notices the first one. Everyone pays for the rest.

Motion gets approved on its first showing and lived with on its ten-thousandth. So the first question I’d ask about any animation isn’t whether it’s beautiful but how often a person will see it. Once, at signup? A few times a week? Every few seconds, all afternoon?

An editor keeps a rough count like this in their head. A cut costs the audience nothing, so you can use a thousand. A dissolve costs a second or two of the audience’s attention, so you spend it where a second or two is what the story needs. Your app has the same budget, and we find the arithmetic dull enough to be convincing. How much does a small animation cost over a year?

Say switching tabs takes a third of a second and someone does it sixty times a day. That’s twenty seconds a day of watching tabs arrive, and across 250 working days it’s about 5,000 seconds: more than an hour and twenty minutes a year, spent on tabs. Nobody would agree to that in writing, and yet we ask it of people every day.

So which parts of your app are cuts? Opening a menu, switching a tab, typing in a search box, moving from one row of a list to the next. Which are dissolves? Finishing setup for the first time, paying, sending off the thing you’ve worked on all week. The first list should snap. The second is allowed a little ceremony.

The rule sharpens once you notice which hand is asking. When you press a key, nothing on the screen is attached to your finger. It’s mechanical: the key goes down and something should be there. Somebody typing at 60 words a minute lands about five letters a second (a word is counted as five characters), and nobody has ever wanted those letters to drift in.

What about a shortcut? Reaching for one is a confession: this person does this so often they memorized a key for it. Give them a cut, not a slow reveal. A menu that scales and fades in after a shortcut feels slow even when it’s technically fast. (It’s an easy thing to be fooled by: a screen that measures as quick and feels like it’s wading through something. The motion is the something.)

A mouse or a trackpad is a softer case: the pointer is already moving, so a little motion on screen joins a movement that’s already underway. A finger on glass is the strictest case of all. There’s nothing between you and the thing, so it has to respond the moment you touch it; a sheet that tracks your thumb feels like holding it, and a sheet that starts moving a beat later feels like it slipped. One app, three dials: silent for keys, quiet for the pointer, generous for the finger, and never late for any of them.

Say there’s a chart of a month of prices, with a small label that shows the price for whichever day your finger is on. Someone suggests the numbers should spin into place like the departure board at a railway station. Sounds nice, doesn’t it? Then you drag across the whole month in a second, and the label is still spinning up toward the eighth while your finger is already on the twenty-fifth.

What you’re seeing isn’t a price; it’s a flicker of digits with no number in it. In a film, this is a dissolve that hasn’t finished when the next shot arrives: two half-pictures on top of each other, and no editor keeps that.

The fix is to do less. While the values are changing faster than the animation can play, show the newest value and skip the show. Our rule of thumb is short enough to put on a sticky note.

If the change arrives faster than the animation, the animation loses, and the newest value wins.

How this goes wrong: say the number on the basket icon bounces every time you add something. You tap “add” five times quickly, and instead of seeing 5 you see a badge jittering somewhere around 3, so you tap once more to be sure. Now there are six in the basket.

Now for the bit where it looks like I’m contradicting myself. I’d take the fade off things appearing, and I’d often keep a short one on things leaving; we’d argue for building it that way. The difference is who’s waiting.

An entrance has an audience: you asked for the thing and you’re standing there waiting for it. An exit doesn’t, because by the time you save, send, or archive, you’ve moved on and nothing you want is behind the thing that’s leaving. Say you swipe a message into the archive and the row folds away in a blink. That short movement is the receipt (it went where you sent it, not into the bin). Take it away and you’re left checking whether you archived it, deleted it, or imagined it.

Films do this too: a scene that’s over ends on a short fade, and nobody waits for it, because the scene is done. So the shape of it is: come in on a cut, leave on a short fade. And I’d keep the exits quicker than the entrances, because a confirmation that lingers is only a new thing to wait for.

I don’t think any of this makes motion the villain. It makes motion expensive, and expensive things get spent where they’ll be noticed.

A good editor doesn’t hate dissolves; they save them for the moment where the story turns, where a season passes, where the character finally gets home, because a dissolve there tells you this mattered. A film that dissolved every cut would feel like it was underwater. Apps have turning points of their own: the account is finally set up, the report is finally sent, the thing you’ve been saving for is finally bought. Nobody is in a hurry at those moments, and a bit of ceremony says the app noticed. (I’d still keep it under a second or so. Ceremony, not a speech.)

What’s the mistake, then? Spreading the ceremony thin. Give every tap a flourish and the flourish goes flat, and the one moment that earned it is treated the same as opening settings. (This, I suspect, is what the designer in your question wants: not everything moving, but an app that feels like someone made it. That ask is right.)

This one is quieter, and it’s the most common version of the mistake we see. A film doesn’t open with the furniture sliding into the room. When the scene begins, the room is already there, because it was there before you arrived.

I think screens should work the same way. If a badge already says 3 when you open the app, it should be there at 3, not grow from nothing to 3 while you watch. If a list was already loaded the last time you were on this screen, it shouldn’t cascade in again, one row after another. Those animations are entrances for things that didn’t just happen, and the eye reads them as the app being slow to get itself together. So should nothing ever move on a screen you’ve just opened? Things that are new can. A message that landed while you were away may slide in, because it’s news; the nine you’d already read should be sitting there.

So here’s a rule I’d pair with the first one: animate changes, not arrivals. Something that changed while you were looking may move. Something that was already true when you looked should simply be there. And if a detail like that can’t be made to behave every single time, on the first frame and the hundredth, I’d rather leave it out than ship it flickering. A detail that’s wrong one time in five reads as broken, not nearly polished.

How do you check any of this? Not by watching it once on the big screen in the meeting room. Here’s what we’d do with the two colleagues in your question, in one afternoon, as a hypothetical (you’ll want both of them in the room for step three):

1. Write down the three things people do most in the app. Take the motion off exactly those three, and use it that way for a day. See who asks for it back (I’d be surprised if anyone does!).
2. Switch on Reduce Motion for a day (on an iPhone it lives under Settings, Accessibility, Motion), and there’s a matching setting for websites that a good site respects. The web’s accessibility guidelines go further and ask that motion set off by an interaction can be switched off unless it’s essential. Whatever you find you can live without was decoration.
3. Spam it. Tap the basket ten times as fast as you can, drag across the chart, hit the shortcut twice, then leave the screen and come back. Bad motion hides in the demo and shows up on the tenth go.

Apple’s own guidance on motion says much the same thing in more polite language: keep it brief, make it optional, and don’t let it get in the way. It’s not a flattering afternoon, and I wouldn’t expect to pass it myself. Most of us find at least one dissolve we’d been calling craft!

So, you, with the designer who wants everything to glide and the engineer who wants it all gone: who’s right? Neither of them wins outright, but the count does. Sit them down with the list of what people do most, and I think you’ll find the engineer is right about nearly everything on it, and the designer is right about the three or four moments that aren’t.

The app won’t get any quicker underneath; whatever it does behind the screen takes as long as it always did. What changes is that nobody is made to sit through the arrival anymore, and to the person holding the phone that is the same thing as speed. And the few dissolves you keep will land harder for being alone, the way the one at the end of a good film does.

In one breath: ask how often it happens, cut the frequent things, keep the keyboard silent, let numbers land, not spin, leave on a short fade, spend the dissolves on the rare moments, never animate what was already there, and turn motion off for a day to see what you miss.

That’s all of it. I hope the next meeting between your designer and your engineer ends with a list instead of a winner, and that the app comes out feeling like a film that knows when to cut.

Hope this helps.