A loading animation reassures when it confirms that work is genuinely underway during a wait the user expects, and it signals a problem when it appears for an action that should be instant or runs so long it starts to read as broken. The deciding question is whether the wait itself is warranted. An indicator is a tool for managing a real wait. It is not a license to excuse an unnecessary one, and a spinner placed in front of something that should have been instant does not make the slowness acceptable, it just announces it.
The logic comes from what the user already expects. People have an internal model of how long things should take: tapping a toggle should be instant, submitting a form that talks to a server can reasonably take a moment, and uploading a large file is obviously going to take real time. When a loader appears for the kinds of operations the user expects to take a beat, it confirms their model, the system is working, and that confirmation is reassuring. When a loader appears for something the user expects to be immediate, it contradicts their model, and the contradiction reads not as reassurance but as a warning that something is wrong.
A concrete pairing shows the split. Imagine submitting a multi step checkout: a brief spinner on the pay button while the charge clears is reassuring, because the user knows money moving takes a moment and the indicator confirms their tap was received and is being handled. Now imagine the same spinner appearing when the user simply switches between two tabs of content already loaded in the page. There the spinner is not managing a warranted wait, it is exposing that something which should have been instant is not, and the user’s takeaway is that the app is slow rather than that it is busy. The component is identical. What differs is whether the wait behind it was justified.
Duration draws the other edge of the line. Even a warranted wait turns into a danger sign if the indicator runs too long. Nielsen Norman Group’s threshold, worth citing rather than guessing, is that around one second is the limit before a user’s flow of thought is interrupted, and a spinner that keeps turning well past the few seconds the user expected stops reading as work in progress and starts reading as stuck or broken. Past that point the honest move is not a smoother spinner but progress information, a percentage, a step count, an estimate, so the user can tell motion from a frozen loop.
One thing to flag is that the indicator is never the fix. The temptation is to add a spinner so the wait feels handled, but a loader on a slow action only dresses up the slowness; it does not remove it. If the same loader appears every single time for an operation that ought to be quick, that is not a UI to polish, it is a performance problem the loader is hiding. Reassurance is a side effect of a wait that was real and brief. It cannot be manufactured on top of a wait that should not exist.
So when you reach for a loading animation, first ask whether the wait it covers is one the user expects and one you cannot make shorter. If both are true, show the loader, and if the wait runs long, upgrade it to real progress. If the wait is one the user expects to be instant, treat the urge to add a spinner as a signal pointing the other way, toward fixing the speed, and leave the indicator out.