Build your own UI pattern library instead of renting one

Product designers and front-end developers build up a private stash of screenshots without ever deciding to: a paywall that converted well, an empty state that made a blank screen feel intentional, a settings page that fit forty options onto one screen without feeling crowded. The habit is sound. What breaks it is where those screenshots end up, usually a Desktop folder, a message to yourself, or a note nobody scrolls back through.

Mobbin exists because that habit is common enough to build a business around. It is a library of screenshots and flows pulled from real apps, organised by screen type and searchable by category, maintained by someone else so you never have to build one yourself. It is a genuinely useful reference. It is also solving a different problem to the one this article is about, and the difference is worth being precise about before you decide which one you actually need.

Why does a personal library beat a subscription to someone else's?

A rented library like Mobbin covers every category at once: consumer apps, B2B tools, games, every platform. That breadth is the selling point and the limit, in the same sentence. If you build settings pages for a B2B product, you do not need three hundred onboarding screens from dating apps sitting between you and the one flow you actually wanted. A personal library only ever contains patterns from your own problem domain, so browsing it is faster, and every result in it is one you already decided mattered enough to keep.

The second difference matters more over a longer stretch of time. A subscription's access ends the day you stop paying for it. Screenshots you took yourself do not. Three years of onboarding flows and pricing pages you personally judged worth keeping is a reference that gets more useful every year you add to it, not a rental you lose the moment the invoice stops.

What actually belongs in it?

Keep the scope narrow enough to stay useful. Onboarding flows, from the first screen to the moment someone reaches an empty home state. Empty states themselves, the ones that explain what is missing rather than just showing a blank rectangle. Pricing pages, especially ones that make a hard trade-off feel like an easy decision. Settings screens that organise more options than they should reasonably fit onto one page. Anything that solved a UX problem you are currently facing, or expect to face again. It is usually the first thing worth pulling together when starting a redesign with research instead of guesswork.

How do you capture a pattern properly?

1. Screenshot the whole flow, not one screen. A single frame of an onboarding step shows you what it looked like. It does not show you how it worked: what happens when someone skips a step, what the confirmation looks like, how a progress indicator moves. Capture every screen in the sequence, in order, or the pattern you saved is only half a pattern.
2. Write down why it works while you still remember. The reasoning is the part that decays fastest. Was the form shorter because two fields got merged into one. Did the empty state use a real screenshot of the finished product instead of an illustration. Was the pricing page's default plan pre-selected on purpose. That reasoning lives in your head for about a day. Write the one sentence before you move on, or you will be reverse-engineering your own judgement from pixels later.
3. Tag it by the job it does, not the company that shipped it. A tag like Notion or Linear tells you where a pattern came from. A tag like progressive onboarding or soft paywall tells you what problem it solves, which is the thing you will actually be searching for the next time you face that problem. File by job, not by source.

How do you actually find it again months later?

This is where the free tools you already have start to show their limits, and it is worth being fair about what they can and cannot do. macOS already indexes the text inside an ordinary screenshot through Live Text, and Spotlight can search it. Apple's own description of the feature, from the release it shipped in, is that Live Text lets people search by text inside images. So a Mac genuinely can find the screenshot with the word Upgrade in it. What it hands back is a list of filenames. You still have to open two or three of them before you recognise the one you meant, because the result is text, not a picture.

A visual library returns the opposite shape of answer: a grid of the actual screens, so you recognise the one you want on sight rather than reading your way to it. That difference sounds small until your collection passes a hundred items, and every search starts costing you several opens just to rule things out.

The free method, and where it stops scaling

You do not need to buy anything for a small collection, and it would be dishonest to pretend otherwise. A plain folder of screenshots with good filenames, something like onboarding-progressive-linear-2026.png, works fine up to a few dozen items, and Spotlight's Live Text search covers the rest. A Figma file works even better for a slightly larger collection: paste each flow onto its own frame, group frames by job rather than by source, and add a text note beside each one.

Both stop scaling for the same reason. A folder depends entirely on the filename carrying the information, so as the collection grows you either write longer filenames or start forgetting what you called things. A Figma file depends on you remembering which page a flow lives on, and Figma's own search matches layer and page names rather than what is actually in the screenshot, so a pattern is only as findable as the label you gave it at the time. Past a couple of hundred items across more than a handful of job categories, both methods turn back into the pile of screenshots this article started with.

Where a dedicated library takes over

A dedicated visual library removes the dependency on you remembering your own filing system. Muse, the app we build, reads the text inside a screenshot the same way Spotlight does, but returns the actual screen in a grid you scan by sight rather than a list of filenames. Every item keeps a note field next to it for the reason you saved it, and one item can sit in more than one collection at once, so a paywall pattern can live under both Onboarding and a specific client project without you duplicating the file or picking one home for it.

It will not replace the three habits in this article: capturing the whole flow, writing the reason down, and tagging by job. Nothing does that part for you automatically, on Muse or anywhere else. What it removes is the ceiling. Whether you end up using a folder, a Figma file or a dedicated library, the collection that is still useful in three years is the one where you did those three things at the moment of saving, not the one you spent the most money on.