I Spent Three Hours Going Through the Page Flows Elements Library and Here Is What Surprised Me Most

I opened Page Flows on a Tuesday afternoon with a pretty simple goal: find a few examples of bottom sheets to reference for a mobile project I was working on. Three hours later I was still there, having gone through toggles, upgrade prompts, empty states, and calendar pickers across dozens of products. That is not what I planned, and I am not sure I regret it.

The elements library at Page Flows, which you can browse here, organizes UI components by type and lets you see how real, shipped products use them in context. What I expected was a reference tool. What I found was closer to a pattern audit of the entire industry.

The Toggle Has a Surprisingly Wide Range

I started with toggles because I needed a quick answer about placement in a settings screen. What I found stopped me for about 20 minutes. The toggle component, which most designers treat as one of the most settled UI decisions in existence, varies enormously across apps. Some products put the label on the left and the toggle on the right, which is the conventional approach. Others flip it. Some use toggles for binary settings. Others use them to trigger actions that take several seconds to execute, which felt like a misuse of the component the more examples I looked at.

What hit me is how differently apps in the same category handle identical decisions. Two productivity apps, both with dark mode toggles in their settings screens, placed the component differently, wrote the label differently, and handled the disabled state differently. Neither was wrong exactly, but seeing them side by side made it obvious that this level of inconsistency across the industry is much wider than I assumed.

The Empty State Is Where Personality Lives

Empty states were the category that genuinely shifted something in how I think about design. I pulled up about fifteen examples and the gap between the best and the worst was significant. The weakest ones showed a gray icon and a short sentence. The stronger ones used the empty state as an extension of the product’s voice, with copy that felt written by the same person who wrote the onboarding.

Success States Are Underbuilt Almost Everywhere

Success states tell a similar story. The library has around 385 examples tagged under this element, and a large share of them are basic green checkmarks with a single line of confirmation text. A smaller group of products treat the success state as a moment worth designing. Some animate the transition. Some add a secondary action that makes sense in context, like sharing a receipt or saving a summary.

Upgrade Prompts Follow Three Patterns and One of Them Works Better

Upgrade prompts were something I had never studied systematically before. The library has over 100 examples, and after looking through a few dozen I could see they cluster into roughly three approaches. The first puts the price front and center immediately. The second leads with the benefit and reveals pricing on a secondary screen. The third uses a soft prompt that surfaces inside a feature the user is already engaging with, which felt the most natural to me by a wide margin. Products like Calm and Headspace use variations of that third approach, and the flows feel noticeably less jarring than the ones that interrupt with a hard paywall.

The Bottom Sheet Section Took the Longest

This is where I originally planned to spend most of my time, and the library delivered. Bottom sheets appear in over 450 examples and cover enough variation that it took a while to orient. The most interesting pattern I found was how different products handle dismissal. Some use a drag handle. Some use an explicit close button at the top right. A few use both. Several apps include neither, expecting a tap outside the sheet to dismiss it, which created a visible problem in flows that had full-screen sheets.

Looking at the examples where the bottom sheet expands to nearly full screen, it became clear that users in those flows were often navigating as if they had landed on a new page. The component was being used in a way that exceeded its intended scope, and you could see that tension in the way the flows handled back navigation.

What Three Hours in the Library Actually Taught Me

The thing I keep thinking about is how much design knowledge lives in the gap between knowing what a component is and knowing how different teams have actually used it across hundreds of shipped products. I knew what a toggle was before I opened Page Flows. I knew what an empty state was. But I did not have a real sense of the range of decisions those simple components contain until I saw them at scale.

The library does not tell you what to do. It shows you what has been done, repeatedly, across different industries and product types, and that turns out to be more useful than I expected going in on a Tuesday afternoon.