Redefining the Wait

An audit of the platform turned up what I called “Hectic Flow”: 16 loading indicators on a single dashboard, 6 different types, no shared logic between any of them. Every squad had solved the same problem alone. The result wasn't just inconsistent. It read as broken.

The fix wasn't prettier spinners. Loading isn't a speed problem, it's an information problem: people tolerate a wait when they can see what's coming. Skeleton screens orient you before the content arrives, so we stopped designing the wait and started designing the preview.

We tested it on the app entrance, rebuilding a passive logo loop into a progressive build.

A good concept doesn't scale on its own. To ship consistent loading across 30+ squads I built a loading design system and specs library: documentation that made the right choice the easy choice.

The One-Loader Rule. One dominant loading treatment per surface, no exceptions. That single rule is what stops Hectic Flow coming back.

Shimmer duration at 720ms, easing curves, and loader colours all became shared tokens. What used to be decided case by case was now already decided.

The system handles most cases. Two didn't fit.

For high-value moments across AI, Docs and Canvas, a generic shimmer undersells what's happening, so we built animated loops that show what the product is actually doing. The wait becomes part of the story.

A shimmer held for twenty seconds reads as frozen. For heavy backend work like exports and duplications, we built progress-segmented loaders that show the work happening in phases, so people stay anchored instead of anxious.

Most loading systems stop at success. But what happens when the result is nothing? A hard cut from loader to empty state reads as failure. I designed the transition as a continuation: the loader flows directly into the empty state, keeping the momentum. The system doesn't fail, it resolves.