There's a specific moment worth noticing: the second time you type the exact same query line, or something close enough to it, is the moment it's worth turning into a saved view instead of typing it a third time next week. Not the first time — a query is only proven useful once it's actually answered a real question, and saving one before that point is guessing at a need against evidence you don't have yet. The steps below are less about a feature to turn on and more about a habit worth building around the query line you're already using.
None of this requires deciding up front how many views to build or what they should all be called. It's a habit that grows out of ordinary use of the query line rather than a setup task to complete before the library feels properly organised — which is itself worth saying, because the temptation to plan a tidy set of views in advance is exactly the trap step one below is written to avoid.
Step 1: Run the query first, save it second
Resist the urge to plan out a set of views before touching the search bar at all. Type the query, look at what it returns, and only reach for "save" once it's clearly the shape of thing you'll want again.
This ordering matters more than it looks like it should. A view saved before it's been tested against real results is a guess dressed up as a shortcut, and the library ends up with views nobody actually opens again — which is its own quiet form of clutter.
It's worth being specific about what "the second time" actually looks like in practice. It's rarely a deliberate decision — more often it's the moment you catch yourself retyping most of a query line you're fairly sure you typed yesterday, or reaching for the same tag-and-rating combination two sessions in a row without planning to. That moment of mild déjà vu is the signal worth acting on, rather than a fixed number of repeats to count up to.
Step 2: Understand what's actually being stored
A saved view stores the query's text, character for character, not a frozen list of which files matched it on the day it was saved. Opening the view re-runs that exact text against whatever the index currently contains, which is the entire reason it's worth saving in the first place — a static list would be wrong within a week, as new files get added and old ones get retagged.
Step 3: Build views around what actually changes, not what's fixed
The views worth keeping are the ones tracking something that moves — an inbox of unreviewed work, a shortlist of favourites for an active project, a "needs a tag" pile that should be shrinking over time. A view built around something permanent, like "everything from 2019," is fine to keep but does less work than one tracking a live state, since a fixed date range never needs re-checking the way an active shortlist does.
Step 4: Let a renamed tag carry the view with it
This is the detail that makes saved views trustworthy rather than just convenient. Because a view stores the query's text rather than a resolved list of matching files, renaming a tag anywhere in the library updates every view built on it automatically — there's no separate step of finding and fixing every saved search that referenced the old name.
Contrast this with a tool that resolves a saved search into a fixed list at the moment it's created: renaming anything downstream breaks the reference silently, and the first sign of trouble is a view that quietly returns nothing. Re-parsing on every open is what avoids that failure mode entirely.
The practical effect shows up most clearly during exactly the kind of cleanup that tends to happen every few months: consolidating two near-duplicate tags into one, fixing a typo that's been bothering you since the tag was first created, standardising a naming convention across a vocabulary that grew organically. Any of that would normally mean an afternoon of also checking every saved search that might reference the old name. Here, that afternoon doesn't need to happen — the views were never holding a copy of the name in the first place, just a pointer to whatever the tag is currently called.
Step 5: Name views for what they answer, not what they contain
A view named "query 3" is a view nobody remembers the purpose of within a month. Naming it after the question it answers — "unrated new arrivals," "client favourites, not yet delivered" — means opening the list of saved views reads like a set of actual questions rather than a row of cryptic strings that all need to be clicked to be understood.
Step 6: Build a small set that covers a real workflow
Rather than saving views one at a time as they come up, it's worth deliberately building three or four that cover the shape of a recurring workflow once that shape becomes clear. A typical spread for an active project: an inbox of everything unreviewed, a shortlist of what's rated highly, and an archive view for everything closed out.
Views are also worth pairing with the tag vocabulary itself rather than treated as an entirely separate habit. A view built around a tag that already answers a real question is far more durable than one built around a one-off combination of rating and date, because a tag is something you're already maintaining deliberately, while a date window quietly stops being the right window the moment enough time passes.
A worked example: three views for a shoot in progress
Say a photo shoot runs for two weeks, with new files landing daily. Three views cover most of what gets asked of it: an inbox of anything added in the last three days and not yet rated, a shortlist of anything rated four or above, and a "needs a decision" view for anything starred but not yet tagged as either kept or cut.
None of the three views needed to be built before the shoot started — each one got saved the second time its query got typed, which was usually within the first two or three days of actual work.
A second worked example: a studio with more than one person searching
The same habit scales past a solo library. A small studio where a few people each register the same shared network folder as their own workspace tends to converge on a handful of views everyone ends up wanting — an inbox of anything nobody's looked at yet, a "cleared for client" shortlist, an archive of closed projects — and because each view is just query text, anyone who knows the tag vocabulary can build one without needing to understand how the underlying index is structured. There's no shared-view feature doing the syncing here; each person's saved-view list is local to their own machine, and what actually travels between them is the tag vocabulary written into the shared folder's files.
What doesn't scale automatically is the vocabulary itself — a view built on
tag:cleared-for-client only works studio-wide if everyone actually uses
that tag consistently, which is a discipline problem rather than something
saved views solve on their own.
Step 7: Prune the list on a schedule, not just when it feels cluttered
A view list that only grows eventually stops being faster to scan than typing a query from scratch. Reviewing it every month or two and deleting anything that hasn't been opened in that window keeps the list itself searchable at a glance, which is the whole point of having saved views rather than a longer and longer row of names nobody fully remembers the purpose of.
Step 8: Use a view to catch problems before they grow
Beyond the obvious "shortcut to a search" use, a saved view is a cheap way
to keep a permanent eye on a specific kind of problem in the library. A view
built around no:tags isn't just a convenience the day it's saved — opened
every couple of weeks, it's an early warning that tagging discipline is
slipping, well before an untagged backlog grows large enough to feel
daunting to clear.
Treated this way, a handful of views function less like search shortcuts and more like a lightweight maintenance dashboard for the library — each one answering "is this specific thing under control" rather than "find me this one file." A useful pair to run alongside each other: one view tracking what's falling behind, and a second tracking what's already handled, so a quick glance at both tells you whether the backlog is actually shrinking or just moving around.
Step 9: Let a view outlive the reason it was first built
Views sometimes turn out useful for a different question than the one they were saved to answer. A view built during one shoot to track "unrated new arrivals" is exactly the same query worth keeping permanently once the shoot wraps, simply repointed at whatever the next project's inbox turns out to be — there's rarely a need to delete and rebuild a view just because the specific files it originally matched have moved on, since the query text itself was never about those specific files in the first place.
Common mistakes worth avoiding
Saving a view the first time a query is typed, before it's proven useful — this is the single most common one and it's what turns a view list into clutter within a month. Building views around a fixed list of files rather than a repeatable question — a view that only ever matches the same twelve files by name isn't really using what saved views are for. And forgetting that a deleted tag leaves a view matching nothing rather than erroring — a view that's gone quiet is worth checking against the current tag list before assuming the library itself has changed.
Where this fits with folders and Finder tags
A saved view isn't a replacement for the folder structure underneath it — it's a layer on top that reaches across folders a fixed tree can't. The tags-versus-folders question covers which jobs each is actually suited to, and saved views are really an argument for tags over folders in one specific case: a question that spans more than one folder, which a saved view answers in one line and a folder structure can't answer at all without duplicating files into two places.
What to do when the library gets large
Views get more valuable, not less, as a library grows, because the cost of retyping a six-clause query rises with how easy it is to mistype one clause by hand. It's worth periodically deleting views that haven't been opened in months — the same discipline as clearing an inbox — so the list stays a set of questions actually worth asking rather than an archive of every query ever typed once.
A view's speed doesn't degrade with scale either, since opening one re-runs a query against an already-built index rather than rescanning the folders on disk — a view answering against forty thousand files returns exactly as quickly as the same view did when the library was a tenth that size, which is what makes it worth building the habit early rather than waiting until the library feels large enough to justify the effort.
The full set of search operators covers every key a view can be built from, and building a consistent tag vocabulary is worth reading before views get built around tags heavily, since a view is only as reliable as the tag it depends on. Getting from scattered folders to something searchable in the first place is the starting point if none of this applies yet, and what a smart folder actually is is worth reading if that's the term this concept is more familiar under. Or try it against your own library — thirty days, every feature, no card and no account — long enough to notice which query gets typed twice.