Building a swipe file as a designer, not a copywriter

Search "how to build a swipe file" and nearly every result assumes you are collecting words: headline banks, subject-line libraries, landing page copy blocks. That is a real skill, and a plain text tool does it far better than anything visual ever will. If you are stockpiling copy, open a Notion database or a single long document instead, and you can stop reading here.

This is written for the other half of the term: designers building a reference library of things they saw and want to see again. UI patterns, page layouts, type pairings, packaging, motion and ads treated as visual objects, not as sentences. If that is you, what follows is what actually keeps a collection like that useful, instead of turning into a folder nobody opens again.

Why do most swipe files stop getting opened?

A swipe file usually starts well and quietly turns into a graveyard within a few months, for a boring reason: everything goes in, nothing gets a reason attached, and eventually you are looking at four hundred screenshots with no memory of why any single one mattered. Browsing a pile like that to find one specific layout takes longer than starting from a blank page, so people stop opening it. A swipe file nobody opens is not a swipe file, it is disk space.

The habit itself is sound. A commenter on a Hacker News thread about notes and links piling up without ever turning into action called swipe files "legitimately high ROI" for design and development work specifically, inspiration and implementation references kept in one place. The return described there is real. What usually breaks is the storage, not the idea behind it.

What should a designer actually save?

Keep it to things you can look at, not things you have to read. UI patterns worth studying the structure of, full page layouts, type pairings that work together, packaging and product photography, motion you would want to reference the timing of, and ads treated as designed objects rather than as copywriting. A screen recording of a transition belongs in a swipe file. A paragraph of headline copy belongs somewhere else, back in that text tool from the opening.

Screenshots are the natural unit here, because most of what is worth saving lives inside an app, a site or a video rather than as a file you can download outright. Get comfortable saving screenshots and short screen recordings as the default capture, and treat a downloaded asset as the exception rather than the rule.

The field almost everyone skips

Every method below gives you somewhere to write a note. Almost nobody uses it, because it costs ten extra seconds at the exact moment you are trying to move fast, and that is the single biggest reason collections stop being useful. A screenshot on its own tells you what something looked like. It does not tell you why you kept it: the way a nav bar collapsed at a certain width, the pairing of two typefaces, the timing of a hover state, the way a packaging box used only two colours. Months later, without that line, you are reverse-engineering your own taste from a picture.

Write the reason in the same sentence you would say out loud if a colleague asked why you saved it. That is usually one line, and it is worth more than any tag or folder name you could apply instead.

Keep the source, and make it searchable, not foldered

Save the URL alongside the image, every time. A screenshot freezes one frame; the source lets you go back and see the actual motion, credit whoever made it, or check whether a pattern still exists on the live site months later. Losing the source is the one mistake in this whole process you cannot fix afterwards, because you cannot un-forget where something came from.

Folders ask you to decide a category at the exact moment you have the least patience for one, which is why most people abandon a folder structure within a project or two. Search does not ask you to decide anything up front. It only needs the note, the source and the image itself to already be there, which is why those three habits matter more than which app ends up holding them.

Four free ways to build one, honestly

None of these need a purchase, and each one has a real limit worth knowing before you commit an afternoon to setting it up.

A Finder folder with tags. The mechanics are built into macOS already, no extra app required.

1. Create one folder for the whole swipe file rather than a folder per project, so everything stays searchable from one place.
2. Save screenshots straight into it, and rename each one with the reason you kept it rather than the default Screenshot timestamp.
3. Add a colour tag in Finder for broad categories such as layout, type or motion, then click a tag in the sidebar later to filter by it.

It is honest and it costs nothing. The limit shows up fast: Finder only searches filenames, so the reason you saved something has to live inside the filename itself, tags are colour-first and run out of colours long before you run out of categories, and a tag lives in Finder's own metadata, so it disappears the moment you share the file with anyone else.

A Notion database. This is the most structured of the free options: a gallery view, a property for the source link, a property for the reason, filters by category. It holds up well for a few hundred items. Past that, a database built around rows of text tends to slow down once most of those rows are carrying an image, because that is not what the tool was built to do first.

Pinterest boards. Free, genuinely visual, and easy to share with a client or a team. The trade-off is who is actually in charge of what you see later: a board lives inside Pinterest's feed and moderation rules, not only yours, so what surfaces when you reopen it is partly the platform's decision rather than only your own filing.

Figma pages. Good for keeping references right next to the file you are designing in, with nothing extra to open. The catch is that a page belongs to one project file rather than to a standing library, and Figma's own search matches layer and page names rather than what is in an image, so a reference is only as findable as the label you happened to give the layer.

Where a dedicated visual library fits in

Every method above works. What they have in common is that you are the search index: the filename, the property, the board title, the layer name all depend on you having typed the right words in at the moment of saving. A dedicated visual library does not replace the three habits in this guide, it removes the dependency on you remembering to apply them. Muse, the app we build, reads the words inside a screenshot the way macOS's own Spotlight does, reads the colours in every image, and keeps a note field next to each item for exactly the reason you kept it, so capturing, sourcing and explaining happen at save time instead of relying on memory later.

It is not a text tool and was never meant to be one, which is worth repeating from the opening: if what you are actually saving is copy, this is the wrong shape of app, and Notion or a document will serve you better. For everything visual, though, a library built this way searches the way you actually remember things, by what something looked like, rather than by which folder you filed it in.