[markhnthoraway]

Depends on context. There's nothing wrong with slowing down to communicate discrete steps that may happen very quickly under the hood.

- Input was received - Input was processed/stored correctly - Outcome is X

Doing everything in real time can reduce confidence and understanding. If everything takes like 5ms it feels weird, sometimes feels even like nothing happened, so people might submit again or feel the need to call and check or whatever.

It's deceptive in the sense that you are waiting maybe 500ms instead of 5ms. But it can be better UX in terms of communicating what's actually going on and having people feel comfortable with their understanding.

On the other hand, artificially slowing down something like closing an advertising modal - antipattern for sure.

[JohnFen]

> There's nothing wrong with slowing down to communicate discrete steps that may happen very quickly under the hood.

I disagree. If the discrete steps happen that quickly, why is it important not only to inform the user of each discrete step, but to slow things down to ensure they can see the notice of each discrete step?

Surely, in a case like that, it would be better just to tell the user the whole process has completed at the end, rather than detail every step that happened on the way there.

[pickingdinner]

Elaborating on details, yes. Slowing it down, no.

If the user is confused as to what happened, you haven't communicated what happened. If you need them to stop and read it, let that notice appear instantly with a next button.

And nothing can happen too fast on a computer. If it's done it's done. Just show "done".