A design reference library is not a collection. A collection is measured by what is in it; a library is measured by what you can get out of it. Almost everyone building one optimizes the first and then wonders why the second never happens.
This is a practical guide to the second. It assumes you already save things and that the saving is not the problem.
The four ways libraries die
Before the system, the failure modes, because a system that does not address these is just a nicer-looking version of the folder you already abandoned.
- Death by capture friction. The tool takes eight seconds and three decisions per item. You use it enthusiastically for a week and then only when you remember, which is never.
- Death by rot. You saved links. The sites redesigned, moved behind a login, or shut down. Roughly a quarter of anything you bookmarked three years ago no longer shows you what you bookmarked it for.
- Death by flatness. You saved images, so the library can only answer "what did it look like" and never "how was it built". It becomes a moodboard, which is fine, but it is not a reference library and it will not help you at 4pm on a Tuesday when you are implementing something.
- Death by scale. It works beautifully at 40 items. At 400 you cannot find anything, so you stop looking, so you stop adding. This one is the most common and the least anticipated, because everything is fine right up until it is not.
Decide what the library is for, narrowly
The libraries that survive are the ones with a stated job. "Things I think are nice" has no job and therefore no criteria for what goes in, which means everything goes in, which means scale kills it.
Useful jobs, pick one or two:
- Implementation reference. Things I will need to build something like, at the level of spacing, type, and interaction detail. Bias toward capturing structure and values.
- Pattern vocabulary. How does this category of product solve this problem: onboarding, empty states, pricing, permissions, settings. Bias toward capturing whole flows and copy.
- Craft study. Specific, isolated details done unusually well: one transition, one focus ring, one loading state. Bias toward small, precise captures with a note on exactly what is good.
- Pitch material. Things to show a client or a team to establish direction. Bias toward whole screens and toward being able to present them side by side.
The bias line matters more than the label. It tells you what to capture, which is the decision you are making twenty times a week.
The capture bar: would I be annoyed to lose this?
A single test, applied at capture time: if this vanished, would I be mildly annoyed? If the honest answer is no, do not save it. Scrolling past something good and not saving it is fine. There is more good design than you will ever need.
This sounds obvious and almost nobody does it, because saving feels free. It is not free. Every item you save is a small tax on every future search. A library of 200 things you genuinely wanted beats a library of 2,000 things you passively hoovered up, and the gap widens over time.
Structure: three levels, not more
Deep hierarchies are where libraries go to die, because filing becomes a decision and decisions become friction. Three levels is the ceiling, and two is usually better:
- Level one: the library itself. One, not per project.
- Level two: kind of thing. Roughly ten buckets, stable over years. Navigation, forms, data display, empty and error states, onboarding, pricing, marketing, motion, typography, color.
- Level three: optional, and only where a bucket actually got big enough to hurt.
Everything else is search. Tags are optional and should be treated as accelerants for searches you actually run, not as an ontology you maintain up front. Add a tag the second time you wish it existed, never the first.
Retrieval is the whole product
The library is worth exactly what you can pull out of it under time pressure. Two things dominate:
First, search that works on meaning rather than on exact words. You will not remember what you called something. You will remember the idea of it. If searching "compact table" only matches items literally containing the words "compact" and "table", your library gets less useful with every item you add. Semantic search inverts that curve.
Second, search over text inside images. A large fraction of most libraries is screenshots, and interface copy is the most distinctive, most memorable thing in them. OCR over your captures turns a dead pile of PNGs back into something addressable.
A concrete benchmark: after six months, you should be able to find a specific item you half-remember in under thirty seconds, more than eight times out of ten. If you cannot, the library is decorative.
Fight rot deliberately
Anything that stores a pointer instead of the thing will rot. Bookmarks rot fastest, then links inside notes, then embeds.
The fix is to store the artifact, not the address. Ideally the artifact is more than a picture: an element capture that carries its markup and computed CSS keeps working as a reference after the source site has been rebuilt twice, because it does not depend on the source site at all.
Keep the URL too, always. It costs nothing and occasionally you want the original context. Just do not let it be the only thing you kept.
A weekly habit that is small enough to survive
One habit, five minutes, and only this one: at the end of the week, open the library and look at what you added. Do not tag, do not reorganize, do not review the whole thing. Just look.
This does two things. It keeps you familiar with your own library, which is most of what makes retrieval fast. And it surfaces the items you saved on autopilot that fail the "would I be annoyed to lose this" test, which you then delete on the spot.
Anything larger than this will not happen, and a habit that does not happen is worse than no habit because it makes you feel like the system is failing when the plan was the thing that failed.
Where Stele fits
Stele is built around the two constraints this post keeps circling: capture the thing rather than a picture of it, and make retrieval work on meaning.
Captures come from a Chrome extension, so an element capture carries its real DOM and computed CSS and stays inspectable after the source changes. Everything lands on one canvas rather than in per-project silos, with full-text search, OCR over images, and semantic search across it. When a reference stops being a reference and starts being something you are building, you can generate React or HTML with Tailwind from it, or hand it to an AI agent as structured context.
The system in this post works in other tools. It works better in one that saves values instead of pixels.