How to Organize a Shared Asset Library

Key Takeaways

• Structure by asset type and subject, not by project or date. Production order is the wrong index for retrieval.
• One canonical version of every asset, and one obvious place for it. Duplicates are the main failure, not gaps.
• Filenames do the work that folders cannot. A good name is findable through search even when the folder is wrong.
• Record the licence and expiry with the asset, or the library becomes a legal liability rather than a resource.
• Someone has to own it. Unowned libraries decay within about a year regardless of how well they started.
• Prune on a schedule. A library that only grows becomes unusable at exactly the size where it should be most valuable.

Structure for Retrieval, Not Production

The default structure is chronological because that is the order work happens: a folder per project, a folder per campaign, a folder per year. It is completely natural and it is the wrong index.

Retrieval questions are almost never chronological. Where is the logo in white on transparent. Where is the founder headshot. Where is that product shot on the grey background. Where is the b-roll of the factory. Each of these is a question about the thing, and a project-based structure forces you to first remember which project produced it.

Organise the top level by asset type, which is the axis people actually search on. Logos, photography, video, illustration, icons, documents, templates, audio. Then one level of subject or subtype underneath: photography splits into people, product, location, events; video splits into finished pieces, b-roll, interviews.

Two levels, then filenames. Beyond two levels you get filing decisions people make inconsistently, and inconsistent filing is worse than a flat folder with good names.

Keep a project archive separately, and let it be chronological. That is a different job with a different question behind it, covered in its own article. The asset library holds the material that gets reused; the archive holds the projects. Conflating them is why most libraries are unusable.

One Canonical Version

The main failure mode of shared libraries is not missing assets. It is six versions of the same asset with no indication of which one to use.

Nominate the canonical version and put it where it is unmissable. The current logo lives at the top of the logos folder. The previous logo lives in an `_Archive` subfolder or is deleted. There should never be ambiguity about which file a person should grab.

Provide the formats people actually need, and no more. For a logo: full colour, mono, reversed, in vector and in a web-ready raster with transparency. That is five or six files. Twenty variants is not thoroughness; it is a decision you have offloaded onto everyone who uses the library.

Say which one to use when it is not obvious. A one-line read-me in the folder covering the three most common cases costs two minutes and prevents the most common misuse.

Sweep for duplicates periodically. The same image at four resolutions in three folders is how libraries become untrustworthy, and once people stop trusting the library they start keeping private copies, which is the beginning of the end.

Filenames Carry the Search

In any library beyond a few hundred items, search is the primary interface and the folder structure is secondary. That makes the filename the most important metadata you have.

Put the searchable words in the name. `Logo_Primary_White_Transparent.png` is findable by typing logo, white, or transparent. `logo-final-3.png` is findable by nobody.

Describe the subject, not the project. `Headshot_Priya_Neutral_2026.jpg` rather than `AcmeLaunch_Shot_047.jpg`. The project is how it arrived; the subject is how it will be sought.

Include the date only where recency matters, which is mostly people and product shots, in `YYYY` or `YYYY-MM-DD` form so it sorts correctly.

Avoid version numbers in a library. Versions belong in a working project. A library holds the current thing; if you need the old one it goes in `_Archive` with the year in the name.

If your storage supports tags or metadata, use them and do not rely on them. Tags are excellent and they do not survive a download, a re-upload, or a platform migration. The filename does.

Record the Licence With the Asset

This is the part that turns a library from an inconvenience into a liability.

Every licensed asset needs its terms recorded where the asset is. Stock photography, music, fonts, illustration, footage, and anything with a model or property release. Not in an email, not in someone's memory. Beside the file.

A simple pattern that works: a `_Licences` folder at the top level, with one document per asset or per purchase, named to match the asset. Plus a line in the library's read-me saying where they are.

Record the expiry, and diarise it. Music licences and stock subscriptions with term limits are the ones that cause problems, because the asset keeps working long after the right to use it lapses, and nobody notices until someone external does.

Mark restricted assets clearly. A photo licensed for social but not for paid advertising should say so in the filename or in a folder that makes the restriction unmissable. `_Restricted` as a folder is blunt and effective.

When the licence cannot be found, treat the asset as unusable and say so in the library rather than leaving it as a trap for whoever needs it next.

Someone Has to Own It

Unowned libraries decay. Not dramatically, just steadily, until the shared drive is a place people avoid and everyone has private copies.

Name one owner. Usually a producer, a designer or whoever handles brand. The role is small: approve what enters, run the periodic prune, and keep the read-me current.

Define what enters. Not everything from a project belongs in the library. Only assets that will plausibly be reused: the finished pieces, the selects, the brand material. Rushes, working files and intermediate exports belong in the project archive.

Make adding things part of project close-out, alongside archiving and the final invoice. If contributing to the library is a separate task with no trigger, it does not happen.

Give people permission to fix things. A library where only the owner can move a file gets one owner-shaped view of correctness and a lot of misfiled items nobody dares touch.

Prune on a Schedule

A library that only grows becomes unusable at exactly the size where it should be most valuable.

Twice a year, an hour. Remove superseded brand assets, expired licences, duplicates, and anything tied to a product or person that no longer exists.

Archive rather than delete when in doubt, into a clearly marked `_Archive` that is excluded from normal browsing. The point is not to destroy history; it is to keep the main library composed only of things someone might actually use today.

Watch for the retired-brand trap. After a rebrand, the old logo must leave the main library immediately, because someone will use it otherwise, and they will be right to, since it was in the logos folder.

Track what people cannot find. Every time someone asks where something is, that is a structure bug. Three of those in the same area means the structure is wrong there, and fixing it is worth more than any amount of reorganising by intuition.

What Tooling Helps

For small teams, cloud storage with a good structure and good filenames is enough, and most teams over-buy here. Google Drive, Dropbox or a NAS with the structure above will serve a team of ten indefinitely.

For larger operations, a digital asset management system adds metadata, permissions, expiry tracking and search that survives migration. The honest threshold is somewhere around the point where licence expiry tracking becomes a job on its own, or where non-team members need self-service access.

The tool does not fix the structure. A DAM with a production-order taxonomy is a faster way to fail to find things.

Storyflow is our product and it is not a DAM. It has no asset management, no permissioned library, no metadata or licence tracking, no expiry alerts and no bulk ingest, so keep the library in cloud storage or a proper DAM. The adjacent job is upstream of the library: gathering and comparing references on a canvas while the work is being decided. Once assets are final and reusable, they belong in storage. Paid-only during early access, with the Free plan landing before the end of 2026, and anyone a paid member invites to a board joins free now.

The Bottom Line

Asset libraries fail for a structural reason that feels natural at the time: they are filed in the order things were made.

Organise by asset type and subject, two levels deep, and keep the chronological project material in a separate archive.

Nominate one canonical version of everything, and provide only the formats people actually need.

Write filenames that carry the search, describing the thing rather than the project, because search is the real interface once a library passes a few hundred items.

Keep licences and expiries with the assets, and mark restricted material unmissably.

Give it an owner and prune it twice a year, because a library that only grows stops being usable exactly when it should be most valuable.

File by what it is, not by where it came from. Nobody searches for the campaign. They search for the logo.