Keeping client work and personal inspiration apart

You are on a screen share, walking a client through moodboard options, and for a second before you switch tabs they see the rest of your library: last weekend's furniture references, a friend's wedding invite, a meme you saved to send someone later. It is a small moment, and it is also usually the one that makes you decide the current setup cannot continue.

That is one version of the same underlying problem. The other two show up later. A contract ends and you need to hand over, or simply delete, everything that belongs to that one client, and it is mixed in with two years of other work. Or you want your own reference library, the things you keep purely for yourself, to follow you from job to job, while whatever you gathered for a specific client stays behind with that client. None of these three are really about tidiness. They are about being able to draw a hard line between what is yours and what belongs to someone else's project, on demand, without an afternoon of manual sorting first.

Where do you actually start?

Before folders, before tags, before anything else, split at the top level. One branch for your own work, one branch for client work. Everything you save decides which side it belongs on at the moment it arrives, not later during a tidy-up session you will never get around to. This single decision is what turns the three failures above from a recurring nuisance into something you can act on in a couple of clicks.

It also answers the screen-share problem directly. If a client project only ever contains that client's material, there is nothing unrelated for them to glimpse when you share your screen, because the personal branch was never in the same place to begin with.

How should client work be organised underneath that?

One collection per client, nested inside the client-work branch, with project subcollections underneath if a client runs more than one job with you at a time. That gives every client a single container. When the contract ends, everything for that client, references you gathered, moodboards you built, screenshots from review calls, sits in one place you can act on as a unit, rather than something you have to hunt through the rest of your library to separate out.

A structured handoff also protects you, not just the client. A designer's own account of running an offboarding process makes the point that closing a project properly, rather than letting it trail off, is the most overlooked part of client work and the part that most clearly separates a professional handover from an awkward one.

Can you do this for free, with Finder alone?

Partway there. Nest a Clients folder with one subfolder per client, and keep a separate top-level folder for your own references. Add a colour tag for anything that cuts across both, mood, medium, a technique you keep coming back to, and Finder will at least filter by tag when you search.

The limitation is real. A Finder alias can point at a file that effectively lives in two places, but move or rename the original and the alias silently breaks, and neither a note nor a tag survives being copied by hand into a second folder. For a couple of clients and a light personal collection, that holds up fine. It stops holding up the moment a single reference genuinely needs to sit inside a client project and inside your own swipe file at the same time, and stay that way without you maintaining two copies.

What about things that legitimately belong to both?

Some material really does span both sides: a photographic style you keep returning to, a colour palette that ends up in most of your briefs, a UI pattern you study regardless of who is paying for the work. Forcing that into one branch or the other is the wrong fix, and it is usually where a structure like this starts to break. Tag it instead. A tag is the right tool for anything that cuts across the split, because it does not force a single home the way a folder does.

Closing out a client, without the mess

Export My Library writes any collection back out as ordinary folders whenever you want, which is exactly what a handover or an end-of-contract archive needs. Point it at the one client collection you built, hand the resulting folder to the client or to your own archive drive, and delete the collection from Muse once you are certain you have everything you need. It is also the natural moment to decide what is worth pulling into your own portfolio, since not everything from a finished project earns a permanent place there.

Worth being plain about one thing here. Muse copies whatever you save into its own library folder, the way Eagle and most dedicated tools do, rather than leaving files exactly where they started. That is precisely why the export step matters: nothing is trapped inside an app-only database, and a client collection can be written back out as real files, in a plain folder, the day you need to hand it over or walk away from it for good.

None of this needs to be complicated. Split personal from client work at the top level before you do anything else, give each client one collection to live in, reach for tags only when something genuinely crosses that line, and keep the export step in mind from the start rather than discovering it in a panic the week a contract ends.