Every guide to design file naming conventions proposes a schema; most teams adopt one enthusiastically and abandon it within a quarter. The failure isn't discipline — it's that the convention asked names to do jobs that belong to metadata, and asked people to care in their scratch space where nobody ever retrieves. A convention survives when it is small, applied only where retrieval happens, and propagated by example instead of policy. Here is that version.
TL;DR
- Names serve the last ten feet of retrieval: a human scanning results and picking one.
- Three parts: what it's for, what it is, what makes it different.
- Dates, versions, initials, and status flags belong in metadata — names carrying them go stale.
- Convention applies at the shared boundary, never in working files.
- Migrate by renaming the ten most-searched assets, not the whole archive.
01 — First principles
What names are actually for
In a library with real search and tags, names have exactly one job left: the moment a person scans a grid of results and picks. Filters got them close; tags did the categorizing; the title does the final disambiguation between six similar banners.
That reframing kills most schema complexity. The name doesn't need to encode the campaign (a tag does), the date (the system tracks it), the author (who cares at retrieval time), or the approval status (that's a state, not a string). It needs to read, at a glance, as the answer to “which one of these is it?”
02 — The pattern
The three-part pattern
Purpose — thing — differentiator. In practice:
Pricing page — Hero illustration — Dark
Q3 webinar — Social card — 1:1
Enterprise one-pager — Deck cover — FR
Each part answers a scanning question in order: what was this made for → what kind of thing is it → which variant am I looking at. Language stays human — the words someone would actually type into search, not codes that need a legend. Separators are punctuation you can read aloud; nobody ever searched for an underscore.
Variants earn the third slot
The differentiator is only for what genuinely varies: theme (dark/light), ratio (1:1, 16:9), language (EN/FR), placement (email vs. social). One asset with no siblings doesn't need one — Pricing page — Hero illustration is complete.
03 — What breaks
The anti-patterns
- Version suffixes. v2_FINAL(3) encodes a revision argument, not an identity. The shared library holds the approved version; supersession is a status change, not a rename.
- Dates as prefixes. 20260214_hero sorts nicely and reads terribly — and the system already knows the date.
- Author initials. Useful for blame, useless for retrieval, wrong the day the file changes hands.
- Encoded taxonomies. MKT-SOC-Q1-BF-004 demands a decoder ring. If information matters for filtering, it's a tag; names are for humans.
- The word “final.” A prophecy that has never once come true.
04 — Adoption
Adopting it without a renaming week
The instinct is a cleanup sprint: rename everything, announce the standard, write the wiki page. Skip all of it. Mass renaming is days of work that touches mostly assets nobody will search again, and rules documents don't change behavior — retrieved examples do.
The migration that works takes an hour:
- Rename the ten most-searched assets to the pattern — the logos, the current campaign kit, the sales one-pagers.
- Apply the pattern to everything new at import, where the one-paste gesture already has you typing a title.
- Fold stragglers into the monthly fifteen-minute pass — three renames a month, forever, quietly.
Within a month, the assets people actually see all read the same way, and the pattern propagates itself. Nobody was policed; nothing was mandated; the example did the work.
05 — FAQ
Common questions
Should the date go in the filename?
Rarely. Creation dates are metadata every system already tracks — putting them in names adds noise and goes stale the first time a file is revised. The exception is genuinely dated deliverables (a webinar, an event) where the date is part of what the asset is.
Do version numbers belong in asset names?
In working files, fine — v1, v2 are cheap iteration markers. In a shared library, no: the library should hold the approved version, and supersession is a status, not a suffix. The moment v2_FINAL and v3_realfinal coexist in search results, trust is gone.
Should working files and library assets follow the same convention?
No. Working files optimize for the designer mid-flow — loose names are fine, they are private scratch space. The convention matters at the boundary: the moment work becomes a shared, finished asset, it gets a scannable title. Policing scratch space is how naming initiatives die.
How do I enforce a naming convention without being the naming police?
Rename the ten most-searched assets to the pattern and stop. People copy what they see when they retrieve — the example propagates further than a rules document, and there is nothing to police. Fix stragglers in the monthly library pass, quietly.
DesignVault leans into this division of labor: titles are free-text and searchable, while campaign, product, and status live as tags and fields — so names never have to carry what metadata already does. Full-text search covers both, in English and French, and renaming an asset takes an edit, not an export. The getting-started guide shows the import flow where titles get typed once, properly.