28 Screen Patterns. Four Have Never Appeared.

The swaggin taxonomy defines 28 screen patterns, from hero and pricing down to command-palette and checkout. After 189 sites and 2,429 screenshots, four of them have never once been tagged. This is a real limit of every public design reference library, including this one, and it is worth stating plainly rather than hiding in a coverage table.

Which four patterns have zero screenshots?

settings, empty-state, notification and error-state. Not one capture across the entire registry. Meanwhile hero appears in 1,051 screenshots and navigation in 847, and both are present on all 189 sites.

Why are they missing?

Because they are behind a login. A capture pipeline visits a public URL and photographs what a stranger sees. Settings pages require an account. Empty states require an account with nothing in it. Error states require breaking something on purpose. Notifications require activity. None of these are reachable from the outside.

This is not a gap in curation effort. It is a property of the public web. Every screenshot library assembled by crawling is subject to it, and the ones that show product interiors either have permission, a paid seat, or a human doing the work by hand.

Why does this matter for a coding agent?

Because these four are precisely the states that separate a demo from a product, and they are the states an agent has the weakest priors for. A model has seen an enormous number of heroes. It has seen comparatively few well-designed empty states, and it cannot retrieve one from a public reference library because none exists to retrieve.

The visible result is familiar. Generated interfaces look convincing at first load and fall apart the moment a list is empty, a request fails, or a user opens preferences. The happy path is over-represented in the training data and in every reference set the agent can reach.

What is thinly covered rather than absent?

Several patterns exist in the registry but at counts too low to be a useful sample. onboarding and paywall have one screenshot each. command-palette and detail-view have two. docs and editor have three. dashboard has 17, which sounds better until you compare it to 1,051 heroes.

What should you do about the gap?

Stop expecting a reference for it and start specifying it. For the four missing patterns, the reference does not exist, so the description has to carry the weight:

1. 01Write the empty state before the populated one. Name what the user sees with zero items, what the single next action is, and whether the illustration is worth its maintenance cost.
2. 02Name the failure modes explicitly. An agent will not invent your network timeout, permission denial and validation states unless you list them.
3. 03Treat settings as an information architecture problem. It is the one screen where structure matters more than style, and where a screenshot would have helped least anyway.
4. 04Borrow structure, not looks, from the patterns that do exist. A well-covered pattern such as pricing can tell you about density and hierarchy even when it cannot tell you about error copy.

Will these ever be covered?

Only through submission rather than crawling. Product interiors need someone with an account who is willing to share them, which is a different pipeline from photographing a public homepage. Until then, four of 28 patterns stay at zero and the honest answer to "show me a good empty state" is that no public library has one.

The short version

• Four of 28 screen patterns have zero screenshots: settings, empty states, notifications and error states.
• All four sit behind a login, so no crawl-based library can reach them.
• These are the states where generated interfaces most visibly fail.
• Several more patterns exist at counts too low to be representative.
• For these, specification replaces reference. Write the states out.