Progress bars communicate system information, like how much cloud storage someone is using in OneDrive, or task information, like how long until a download is complete.
Progress bars should only be used for tasks that take longer than a second. If you’re loading new content with a known structure that doesn’t block the UI, try a skeleton.
Static progress bars
Use progress bars with no animation to communicate a static percentage. For example to show system progress scenarios, like indicating how much storage is left.
Determinate and indeterminate
Progress bars can be either determinate or indeterminate, depending on the needs of your app and the capabilities of the technology you’re building on.
Determinate progress bars let people know how much of a task has been completed and how much remains. Use determinate progress bars whenever possible. They offer a better user experience than indeterminate progress bars since they communicate status and assure people things are still working.
Sometimes, it’s not possible to gauge how long something will take and it’s necessary to use an indeterminate progress bar. Indeterminate progress bars don’t provide any reassurance that things are still working, so only use them for short tasks. Watching the bar cycle for too long could make people think something’s gone wrong.
If enough data is gathered after a task starts and it becomes possible to communicate how much time is left, switch to a determinate progress bar. If there’s very little time left, complete an animation cycle before transitioning from the loading state. Don’t interrupt an indeterminate progress bar in the middle of an animation.
Combine related steps into one progress bar to avoid “rewinding” the bar. For example, if checking for updates and then installing updates, only show one progress bar. Change the status text when the installation starts but continue to move the progress bar forward from the same point.
When the bar appears to move backward, people lose confidence in it.
Combine multiple steps of a longer task into one progress bar
Restarting the progress bar for each task step can make people lose confidence
A progress bar can appear in a new drawer, in a callout, or under the UI that initiates the task. It can even replace the initiating UI if the UI can return to its original state if the task is canceled.
If the task can be canceled, place a Close button in the upper right, aligned with the baseline of the progress bar label.
1. Label (optional) is short and clear. Use sentence case with no period.
2. Status (optional) communicates what’s happening now or how much progress has been made. Use units that are informative and relevant.
Keep labels short and clear
Include a short label above the progress bar that describes what’s taking place. Don’t include a period. For more information, see Periods in the Microsoft Writing Style Guide.
Use status text for additional info
Use status text to communicate how much progress is being made, set expectations for how long a task might take, or to let people know what could happen if they don’t wait.
Use descriptive -ing verbs for communicating a task’s progress. Keep it brief and end with an ellipsis to communicate the task is ongoing. Use a space before the ellipsis.
Use units that are informative and relevant to give the best idea of how long the task will take to complete. Avoid time units—they’re rarely accurate enough to be trustworthy.
Avoid time units in status text
When an error occurs, replace the status text with an error message. Use specific, concise verbs to communicate what went wrong and what people should do next.
Use an error to communicate when a task can’t continue