A component library is code you own. A pattern library is evidence you have gathered. The two get confused constantly, and the confusion is expensive: teams try to build a pattern library out of components, which produces a Storybook nobody reads, or they try to build a component library out of screenshots, which produces a Figma file nobody trusts.
This is about the second thing. You are collecting real implementations of a problem, from the wild, so that when you have to solve that problem you are arguing from evidence instead of from taste.
Collect by problem, never by component
The instinct is to file things under "dropdowns", "modals", "tables". This is the wrong axis and it is why most pattern collections are useless.
File by the problem the interface is solving. "Choosing one of many when the list is long." "Confirming something destructive." "Showing that data is partially loaded." "Explaining why a thing is disabled."
The reason is that when you sit down to work, you have a problem, not a component. If your library is organized by component you have to already know the answer in order to find the evidence, which defeats the purpose. Organized by problem, the library hands you eight solutions to compare, several of which are not the component you assumed.
A good pattern folder is unbalanced on purpose: twelve examples of a hard problem, one example of an easy one.
What to record about each example
The capture is not enough on its own. Each example needs a small amount of context, and the trick is keeping it small enough that you will actually write it.
Four fields, all optional, none longer than a line:
- The constraint. What was true about this product that made this solution reasonable. "Enterprise, so the list is 400 items." "Consumer, so no learning curve budget."
- The trade. What it gave up. Every solution gives something up and the ones that appear to give up nothing are the ones you have not understood yet.
- The detail. The specific thing you want to steal, if there is one. "The way the count updates while filtering."
- The doubt. Anything that looks wrong to you. Future-you will want to know that past-you was suspicious.
The doubt field is the one people skip and the one that makes a library feel like it was assembled by someone with a point of view rather than a scraper.
Twelve examples beats one good example
Volume, per problem, is what makes a pattern library work. One reference is a preference. Twelve references is a distribution, and a distribution tells you things a preference cannot:
- What is conventional, which is what your users already know how to do.
- What the tails look like, which is where the interesting ideas are.
- Which parts everyone does the same way, which is usually where the real constraint is hiding.
- Which parts vary wildly, which is where you actually have a decision to make and should spend your thinking.
This last one is the highest-value output of the whole exercise. Most of a screen is 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 there.
Capture implementations, not pictures
This matters more for a pattern library than for a general inspiration library, because pattern work is comparative and pictures cannot be compared on the axes you care about.
If you have captured the actual elements with their computed styles, you can ask questions across a folder: what is the median row height in these twelve tables, do any of these use a real disabled attribute or are they all a class, how many of these focus rings meet contrast, what is the spacing scale everyone converged on.
If you have twelve screenshots, you can look at twelve screenshots. That is a categorically weaker input, and it is why so many pattern collections end up as vibes.
The three-pass method
A repeatable way to work a problem, roughly ninety minutes.
Pass one, breadth, thirty minutes. Find ten to fifteen products that have this problem and capture their solution with no judgment at all. Include the bad ones. Include the two you think are wrong. Do not write notes yet; notes slow you down and bias the sample toward whatever you noticed first.
Pass two, annotate, thirty minutes. Go back through and fill in the four fields. This is where you notice that four of them are the same solution and you had not seen it, and that the one you thought was bad is solving a constraint the others do not have.
Pass three, decide, thirty minutes. Write down what is conventional, what varies, and which two decisions are open. Then make those two decisions, in writing, with the reason. That written decision is the actual artifact. The captures are its footnotes.
Keeping it alive
Pattern libraries rot in a specific way: the products you captured redesign, and your evidence becomes historical without you noticing. Two defences.
Store the capture, not the link. If what you saved carries its own markup and styles, it does not matter that the source changed. You have the evidence as it was, which is what evidence is supposed to be.
Date everything and treat the date as load-bearing. A convention from 2021 is a different claim from a convention from this quarter. If your library does not show you the date at a glance, you will silently argue from stale evidence.
When to promote a pattern into code
The bridge from pattern library to component library, which is the part most people never build.
Promote when the same problem has come up three times in your own product and you have made the same decision each time. Not before. A component built from one occurrence is an abstraction over one example, which is how design systems accumulate components nobody uses.
When you do promote, keep the pattern folder linked to the component. Six months later somebody will ask why the component works this way, and the answer is twelve captures and a written decision, which is a much better answer than "that is how it has always been".
Doing this in Stele
This workflow is close to the 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 inspect and compare, not twelve pictures.
Folders map onto problems, sticky notes carry the four fields, and search runs across everything including text read out of images. When a pattern is ready to become code, you can generate React or HTML with Tailwind from the capture, or hand it to your AI agent as structured context.
The method works without any particular tool. It works considerably better when the evidence is inspectable.