A design reference library isn’t a collection. A collection is judged by what’s in it. A library is judged by what you can actually get back out of it, and almost everyone building one optimizes the first thing and then wonders, months later, why the second thing never happens.
This is about the second thing. It assumes you already save stuff, and that saving was never really your problem.
The four ways libraries die
Before we get into how to build one, it helps to know how these things fail, because a system that doesn’t address these is just a nicer looking version of the folder you already gave up on.
- Death by friction. The tool takes eight seconds and three decisions per item. You’re diligent for a week, then you only use it when you happen to remember, which turns out to be never.
- Death by rot. You saved links. The sites got redesigned, moved behind a login wall, or just disappeared. Roughly a quarter of anything you bookmarked three years ago doesn’t show you what you bookmarked it for anymore.
- Death by flatness. You saved images, so the library can only ever answer "what did it look like" and never "how was this built." It turns into a moodboard, which is fine on its own terms, but it won’t help you at 4pm on a Tuesday when you’re actually trying to implement the thing.
- Death by scale. It works great at 40 items. At 400 you can’t find anything, so you stop looking, so you stop adding. This is the most common failure and the one people see coming least, because everything feels fine right up until it isn’t.
Decide what the library is actually for
Libraries that survive have a job. "Things I think are nice" has no job, and without one you have no criteria for what belongs, which means everything belongs, which is exactly how you end up at death by scale.
Pick one or two of these:
- Implementation reference. Things you’ll need to build something like, down to the spacing, type, and interaction details. Bias toward capturing structure and real values.
- Pattern vocabulary. How does this category of product solve onboarding, empty states, pricing, permissions, settings. Bias toward capturing whole flows and the actual 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’s good about each one.
- Pitch material. Things you can show a client or a team to point at a direction. Bias toward whole screens you can lay side by side.
The "bias toward" line matters more than the label does. It tells you what to actually capture, which is a decision you’re making twenty times a week whether you notice it or not.
The capture bar: would losing this actually annoy me
One test, applied every time you’re about to save something. If it vanished right now, would you be even a little annoyed? If the honest answer is no, don’t save it. Scrolling past something good without saving it is completely fine. There is more good design out there than you will ever need.
This sounds obvious and almost nobody actually does it, because saving feels free. It isn’t. Every item you save is a small tax on every future search you’ll ever run against that library. Two hundred things you genuinely wanted beats two thousand things you passively hoovered up, and that gap only gets wider with time.
Structure: three levels, no more
Deep folder hierarchies are where libraries go to die, because filing something becomes a decision, and decisions become friction. Three levels is the ceiling. Two is usually better.
- Level one: the library itself. One, not one per project.
- Level two: kind of thing. Around ten buckets, stable for years. Navigation, forms, data display, empty and error states, onboarding, pricing, marketing, motion, typography, color.
- Level three: optional, and only where a bucket has actually gotten big enough to hurt.
Everything past that is search, not folders. Tags are optional, and they should work as accelerants for searches you actually run, not as some ontology you maintain up front out of a sense of duty. Add a tag the second time you wish it existed, never the first.
Retrieval is the whole point
A library is worth exactly what you can pull out of it under time pressure. Two things decide that.
First, search that understands meaning rather than exact words. You won’t remember what you called something. You’ll remember the idea of it. If searching "compact table" only matches items that literally contain those two words, your library gets worse with every single item you add to it. Meaning-based search flips that curve the other way.
Second, search over the text inside images. A huge chunk of most libraries is screenshots, and interface copy is often the single most memorable, most distinctive thing in them. Run OCR over your captures and a dead pile of PNGs suddenly becomes something you can actually find your way back into.
A concrete benchmark worth holding yourself to: six months in, you should be able to find something you half remember in under thirty seconds, more than eight times out of ten. If you can’t, the library is decoration.
Fight rot on purpose
Anything that stores a pointer instead of the actual thing will rot eventually. Bookmarks rot fastest, then links buried in notes, then embeds.
The fix is to store the artifact, not the address. Ideally that artifact is more than a picture. An element capture that carries its own markup and computed CSS keeps working as a reference even after the source site has been rebuilt twice, because it doesn’t depend on that site existing anymore.
Keep the URL too, always. It costs nothing, and every so often you want the original context back. Just don’t let it be the only thing you kept.
A weekly habit small enough to actually survive
One habit, five minutes, and just this one. At the end of the week, open the library and look at what you added. Don’t tag it, don’t reorganize it, don’t review the whole thing. Just look.
This does two things at once. It keeps you familiar with your own library, which is most of what makes retrieval feel fast. And it surfaces the stuff you saved on autopilot that fails the "would I be annoyed to lose this" test, so you can delete it right there on the spot.
Anything bigger than this won’t happen, and a habit that doesn’t happen is worse than no habit at all, because it makes you feel like the system failed when really the plan was the thing that failed.
Where Stele fits
Stele is built around the two constraints this whole post keeps coming back to: capture the thing itself instead of a picture of it, and make retrieval actually work on meaning.
Captures come from a Chrome extension, so an element capture carries its real DOM and computed CSS and stays inspectable long after the source changes. Everything lands on one canvas instead of getting scattered across per-project folders, with full text search, OCR over images, and semantic search across the whole thing. When a reference stops being a reference and starts being something you’re actually building, you can generate React or HTML with Tailwind straight from it, or hand it to an AI agent as real structured context instead of a screenshot.
Everything in this post works in other tools too. It just works a lot better in one that saves values instead of pixels.