The four seconds before content arrives are not a mystery state. They are a design decision waiting for tokens.
Most design systems cover the loaded state in detail and leave the loading state to whatever the frontend framework ships by default, usually a spinner with no clock and no shape. Skeleton tokens close that gap by naming the four values a real skeleton needs: a shimmer duration (how fast the sheen sweeps), a radius for text placeholders, a radius for avatar placeholders, and a base opacity floor so the ghost never reads as fully-formed content. The trick is that a skeleton is not a guess about the layout that will eventually load, it is the exact layout, drawn before the data exists, so the same card component renders both states from the same markup with different fill values. That is also why the shimmer duration deserves its own token rather than reusing a generic motion-duration value: a shimmer under about a second reads as flickering, and one over two seconds reads as broken, so 1.4s becomes a considered decision instead of whatever number felt fine in one component. Once all four values are named, every loading state in the product, list rows, cards, profiles, pulls from the same four tokens, and a designer reviewing a new screen has a real answer for "what does this look like before the data shows up" instead of an improvised spinner.
Leave a Reply
You must be logged in to post a comment.