Make the slow part visible.
Waiting is easier to understand when the interface shows what it knows. Explain the work without inventing a countdown.
Suppose a little design tool turns a collection of drawings into a large printable poster. You choose the drawings, arrange the page, and press “Prepare poster.”
The button goes gray. A spinner appears. After a while, the spinner is still having a wonderful time.
Is the tool reading the files, building the page, or waiting for somewhere to save it? The animation gives no clue. It shows movement, which is not quite the same thing as showing work.
A slow operation deserves an interface of its own. That interface should describe the wait as honestly as the finished result.
A stage can be more useful than a percentage
For this imaginary poster tool, it might be possible to distinguish reading the drawings from rendering the final page. Show the current stage if the application can observe it. A completed stage should stay completed; do not make the label rotate through reassuring phrases on a timer unrelated to the work.
If the tool has read eight of twelve drawings, that is something specific to report. It does not automatically mean the whole task is two-thirds finished. The remaining drawings could take longer to process, and preparing the final page is still ahead.
Name the unit: “Reading drawing 8 of 12.” Save a percentage for a quantity the tool actually measures. If it cannot estimate the remaining work, a plain stage label is better than an invented number that parks at ninety-nine percent.
A duration estimate needs evidence too. Some tasks vary with the input or the connection. It is fine to say that the duration is not known. Someone can make a more sensible choice with an honest limit than with a countdown that keeps granting itself an extension.
Show where the finished poster will appear. Waiting should not end with a new scavenger hunt for the result.
Let the person do something else
A waiting screen should make clear whether leaving it interrupts the operation. If the work continues elsewhere, explain how to return to its status. If closing the window abandons the job, say that before someone closes it.
Do not imply background processing merely because it would be convenient. This explanation has to follow the implementation.
For the poster example, the person might be able to keep adjusting a separate draft while the selected version renders. If so, identify which version is being prepared. Otherwise an apparently helpful editable screen can create a new uncertainty: did that last change make it into the file?
Keep meaningful status text available without requiring someone to stare at an animation. Avoid stealing keyboard focus each time a stage advances. The result can ask for attention when it is ready, rather than making every small update an interruption.
To review the design, deliberately slow the operation in a test environment. Read the screen at different points. Check what it says before the first observable result and after the last input has been processed but the final file is not ready.
During the wait, someone needs enough information to decide whether to keep the window open or get on with something else. A spinner can keep its hobby. The person has a poster to make.