I am currently designing a very complex enterprise application. I have done some research on loading states and came to the conclusion that loading states that should be displayed depends on scope, frequency, duration, and what the user is doing in the application.

My question is; should loading be consistent everywhere in the same application? Or can this change depending on the scenario and what the user is actually doing.

For example, a user navigating to page with a data table that has many records could see a skeleton screen loading. While in the same application, a user updates a profile page and then hits a "Save" button could see a loading spinner on the button instead of a skeleton screen.

I am of the personal opinion that loading states should change depending on what the user is doing and the expected amount of time for the application to respond. However I can see some might point out that this is NOT inline with usability heuristic of Consistency & Standards but I don't think it makes sense to use skeleton loading or a loading spinner everywhere no matter what.

Please let me know if there is any additional information where I could find best practices on this.

Thank you

  • See if this answers your question ux.stackexchange.com/questions/148250/… Basically, you can have the skeleton or spinner set to always load. If the app is fast enough, users won't see anything, although sometimes they might see a FOUC. Thus, you can set a minimum of .5 to 1 seconds for fast loading pages to avoid FOUC, then use skeletons or spinners on all other pages as needed
    – Devin
    Commented Aug 25, 2023 at 19:57

3 Answers 3


Sometimes heuristics conflict with each other, and this is one of those cases. Getting "visibility of system status" right is more important here than using just one loader type for the sake of consistency.

If the system knows how long a loading will take, it should show an estimate with a determinate loader.

If the system can't estimate the loading time, it should use an indeterminate loader (like a spinner), or a skeleton screen.

Skeleton screens are a nicer experience when a page has a large amount of unloaded content - it gives the user more information on what to expect than a blank page with a spinner.

A spinner is good when the system is "thinking" on an update to existing content that's already on the page (as one example).

If you want to apply consistency and standards, you'll want each of these loader types to look and behave the same across your platform.


Apart from the spinner and skeleton loader, I would love to share two more variations.

  1. Toast Sketch of toast

Toast becomes very handy when you use it in complex data tables. You can even override labels to make the impression more intuitive. IMO, you can optimize the design more by placing the toast at the bottom-left of the UI.

  1. Progress bar on top of the screen Sketc of top progress bar

You can also play with the progress bar in the enterprise/SAAS applications by placing it on top of the header component. Here, labels can play an important role by showing the progress with short details.

I have attached sketches and relevant links for both components. Check these out and explore. Best of luck.


In UX design, creating context-based solutions is crucial, and consistency plays a significant role not only in the UI but also in various scenarios. For example, defining loading states, like using skeletons for data-heavy UI screens and spinners for buttons, is indeed a great practice to enhance the user experience. 😊

  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Sep 25, 2023 at 12:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.