I have no love for skeletons. They feel clever at first, but as a user, I associate nothing but bad experiences with them. I feel the same way about PWA app she

I have no love for skeletons. They feel clever at first, but as a user, I associate nothing but bad experiences with them. I feel the same way about PWA app shells. With no theories to back this up whatsoever, here's my completely unsubstantiated gold-standard strategy for loading states: 1. Make it fast. Most of the examples are loading content. Is there any reason you need more than 100ms to do that? Buy a bigger database server and use a CDN/Edge. Prefetch some content. Unlike fancy skeleton designs, this is worth obsessing over and spending money on. Why "trick" users when you can just perform so well you don't have to. 2. Instantly give inline feedback that an action was started. Could be a spinner on the button, text below the button, a toast / non-modal overlay, a loading indicator in the top right... If you get your response in 100ms, you don't really need this, but the network could always be slow etc. 3. Wait some time (something like 1 second imho) to see if you can transition to new finished state 4. If the full transition can't happen in the timeout, transition to a full loading state. I don't think it even matters that much what kind. Could be a spinner screen, a skeleton screen. No modal overlays though unless a destructive/uninterruptible action like a booking or payment is taking place. 5. Show an indicator/overlay if network quality is bad. The user will not blame it on you and have no expectations for your app to behave particularly well. Of course if you can just make a fast loading website, let the browser handle the transitions. It's already a fine loading experience.