A component library is code you own. A pattern library is evidence you’ve gathered. The two get mixed up constantly, and mixing them up is expensive. Teams try to build a pattern library out of components and end up with a Storybook nobody reads, or they try to build a component library out of screenshots and end up with a Figma file nobody trusts.
This post is about the second thing. You’re collecting real implementations of a problem, straight from the wild, so that when you actually have to solve that problem you’re arguing from evidence instead of from taste.
Collect by problem, never by component
The instinct is to file everything under "dropdowns," "modals," "tables." That’s the wrong axis, and it’s why most pattern collections end up useless.
File by the problem the interface is actually solving instead. "Choosing one of many when the list is long." "Confirming something destructive." "Showing that data is only partially loaded." "Explaining why something’s disabled."
The reason this matters is that when you sit down to work, you have a problem, not a component. Organize your library by component and you have to already know the answer just to find the evidence, which defeats the entire purpose. Organize it by problem and the library hands you eight different solutions to compare, several of which aren’t even the component you originally assumed.
A good pattern folder is deliberately lopsided. Twelve examples of a hard problem, one example of an easy one.
What to actually write down about each example
The capture alone isn’t enough. Each example needs a little context, and the trick is keeping that context small enough that you’ll actually write it every time.
Four fields, all optional, none longer than a line:
- The constraint. What was true about this product that made this particular solution reasonable. "Enterprise, so the list runs 400 items deep." "Consumer, so there’s no budget for a learning curve."
- The trade. What it gave up to get there. Every solution gives something up, and the ones that look like they gave up nothing are the ones you just haven’t understood yet.
- The detail. The one specific thing worth stealing, if there is one. "The way the count updates while you’re filtering."
- The doubt. Anything that looks off to you. Future you will want to know that past you was already suspicious.
The doubt field is the one people skip, and it’s the one that makes a library feel like it was put together by someone with an actual point of view instead of a scraper.
Twelve examples beats one good example
Volume, per problem, is what actually makes a pattern library work. One reference is just a preference. Twelve references is a distribution, and a distribution tells you things a single preference never can:
- What’s conventional, which is what your users already know how to do without thinking.
- What the tails look like, which is usually where the genuinely interesting ideas are hiding.
- Which parts everyone does the exact same way, which is usually where the real constraint is buried.
- Which parts vary wildly, which is where you actually have a decision to make and should be spending your thinking time.
That last one is the highest value output of this whole exercise. Most of a screen is just convention, and you should spend zero design effort on it. The library tells you which two decisions are genuinely open, so you can put your attention exactly there instead of everywhere at once.
Capture implementations, not pictures
This matters even more for a pattern library than for a general inspiration library, because pattern work is fundamentally comparative, and pictures can’t be compared on the axes you actually care about.
If you’ve captured the real elements with their computed styles, you can ask questions across a whole folder at once. What’s the median row height across these twelve tables. Do any of these use a real disabled attribute, or are they all just a class doing the visual work. How many of these focus rings actually meet contrast. What spacing scale did everyone independently converge on.
If all you have is twelve screenshots, you can look at twelve screenshots. That’s a categorically weaker input, and it’s exactly why so many pattern collections end up being pure vibes.
The three-pass method
A repeatable way to actually work through a problem, roughly ninety minutes start to finish.
Pass one, breadth, thirty minutes. Find ten to fifteen products that have this same problem and capture their solution with zero judgment. Include the bad ones. Include the two you already think are wrong. Don’t write notes yet. Notes slow you down here and bias the sample toward whatever you happened to notice first.
Pass two, annotate, thirty minutes. Go back through and fill in the four fields. This is usually where you notice that four of your examples are actually the same solution and you just hadn’t seen it, and that the one you thought was bad is solving a constraint none of the others even have.
Pass three, decide, thirty minutes. Write down what’s conventional, what varies, and which two decisions are genuinely open. Then make those two decisions, in writing, with the reasoning attached. That written decision is the real artifact here. The captures are just its footnotes.
Keeping it alive
Pattern libraries rot in a very specific way. The products you captured get redesigned, and your evidence quietly becomes historical without you noticing it happened. Two defenses against that.
Store the capture, not the link. If what you saved carries its own markup and styles, it doesn’t matter one bit that the source changed later. You still have the evidence exactly as it was, which is what evidence is actually supposed to be.
Date everything and treat that date as load-bearing information. A convention from 2021 is a completely different claim than a convention from this quarter. If your library doesn’t show you the date at a glance, you will end up silently arguing from stale evidence sooner or later.
When to promote a pattern into real code
This is the bridge from pattern library to component library, and it’s the part most people never actually build.
Promote a pattern once the same problem has come up three separate times in your own product and you’ve made the same decision each time. Not before that. A component built off one occurrence is just an abstraction over a single example, which is exactly how design systems end up full of components nobody uses.
When you do promote one, keep the pattern folder linked to the component. Six months later somebody will ask why the component works this particular way, and the answer being twelve captures plus a written decision is a much better answer than "that’s just how it’s always been."
Doing this in Stele
This workflow is close to the actual reason Stele exists. Captures come from a Chrome extension, and an element capture carries its real DOM and computed CSS, so a folder of twelve solutions to one problem is twelve implementations you can genuinely inspect and compare, not twelve pictures sitting side by side.
Folders map onto problems, sticky notes carry the four fields, and search runs across everything including text read out of images. When a pattern’s ready to become real code, you can generate React or HTML with Tailwind straight from the capture, or hand it to your own AI agent as structured context.
The method works fine without any particular tool behind it. It just works a lot better once the evidence is actually inspectable.