The taxonomy workshop produces a beautiful structure. Seven levels deep, mutually exclusive at every branch, exhaustively covering the material. The person who built it can find anything in it in four seconds.
Nobody else can find anything in it at all, and within a year half the assets are sitting in a top-level folder called To Be Sorted.
Short answer: stop building a tree and build facets. A tree forces one classification and requires the user to guess the designer’s mental model. Facets let several independent dimensions intersect, so anyone can start from whichever one they happen to know. Three to six facets with governed vocabularies will outperform any hierarchy you can design, and they are far easier to maintain.
Why deep hierarchies fail
Three reasons, and only the third is about the design.
Users do not know where things go. A hierarchy asks you to reproduce the classifier’s reasoning. Is a photograph of a product being used by a customer filed under Product, under Lifestyle, or under Campaign? Any answer is defensible, which means the filer guesses and the searcher guesses differently.
Real material does not partition cleanly. Taxonomy in the strict sense) requires mutually exclusive categories. Marketing assets are not mutually exclusive. A single image is simultaneously product photography, spring campaign, German market, approved, and licensed until 2027. A tree makes you pick one of those as primary and hide the rest.
Depth multiplies error. Each level is a decision with a failure rate. Seven levels at ninety percent accuracy each gives you a bit under fifty percent chance the asset is where anyone expects. That is not a training problem, it is arithmetic.
The facet model
Replace the single hierarchy with a small number of independent dimensions. A query is the intersection.
A typical enterprise set:
- Asset type. Photography, illustration, logo, video, document, icon. Shallow and closed. Rarely more than a dozen values.
- Business context. Brand, business unit, or product line, depending on how your organisation is actually shaped. This one mirrors the org chart and therefore needs a refresh path when the org changes.
- Subject. What is depicted. The largest vocabulary and the one most worth basing on a standard rather than inventing, since the Getty vocabularies already cover most subject, material and place terms.
- Market or locale. Where it may be used. Closed list, taken from wherever your organisation already maintains market codes.
- Status. Draft, in review, approved, superseded, expired. Small, closed, and the single most valuable facet in the set, because it is what turns a library into something you can trust.
- Rights. Owned, licensed, restricted, expired. Also small, also closed, and it carries the legal exposure described in rights and expiry as first-class asset data.
Six facets, each shallow, each independently selectable. That structure answers “approved product photography cleared for Germany” without anyone knowing a folder path, and it answers “everything expiring next quarter” too, which no tree does.
Note what is not in the list: date and campaign. Both are usually better as filters over structured fields than as facets, because they are continuous or unbounded, and unbounded facets become scroll lists nobody reads.
How deep should a facet go?
Two levels. Three at the absolute limit, and only for subject.
The reason is that a facet is displayed as a list you scan, not a path you traverse. Past about thirty visible values, scanning fails and people stop using the facet. If a dimension genuinely needs more values than that, it wants type-ahead search rather than a browsable list, and that is a different interface affordance.
The practical rule I use: if a facet value has fewer than about five assets under it and is not going to grow, it should not be its own value. Merge it upward. A vocabulary with two hundred terms where a hundred and forty are used once is a vocabulary that has failed and is generating noise.
Governing the vocabulary
This is the part that determines whether the taxonomy is alive in three years or fossilised.
Someone owns each vocabulary. Named. With a documented process for proposing, approving and retiring terms. Unowned vocabularies grow monotonically, because adding is easy and removing is frightening.
Additions require a case. Not a hard case, but a stated one: what search failed without this term. That single question kills most requests and improves the rest.
Synonyms map to a preferred term. Auto, Car, Vehicle and Automobile should be one concept with three non-preferred labels, not four terms. ANSI/NISO Z39.19 is the standard covering exactly this construction and is worth reading once before you build.
Deprecation is a state, not a delete. Retire a term and remap existing assets. Never delete a term that is in use, because the assets do not disappear, they just become uncategorised.
Review quarterly, with data. Term usage counts, zero-result searches, and facet click-through. Half an hour of numbers prevents years of drift.
Where does free tagging fit?
Somewhere between “useful” and “a slow-motion disaster”, depending entirely on governance.
Open tagging feels democratic and produces product, products, Product, product-shot and prodshot inside a quarter, at which point the tag facet is noise and people ignore it. If you want the flexibility, the workable compromise is a two-tier arrangement: a governed vocabulary that drives facets and filters, plus a free-text keyword field that feeds full-text search only and never appears as a facet. Users get to write what they like, and the navigation stays clean.
Automated tagging changes this calculation somewhat, and it is worth being precise about how. Machine analysis is consistent, which is its main advantage over human tagging: it will call the same thing by the same name every time, which is exactly what human taggers fail to do. It is also frequently generic, and it does not know your business vocabulary. Cloudinary’s asset analysis will reliably tell you an image contains a person, a chair and daylight. It will not tell you it is the Q3 campaign key visual.
So the sensible split is: machine tags populate the subject facet and full-text search, humans populate business context, status and rights. Machines are good at what is in the frame and useless at what it is for.
How do you tell if the taxonomy is working?
Four numbers, collected quarterly. Same discipline as the schema review in the metadata schema an enterprise actually needs, and often the same meeting.
- Zero-result rate. Proportion of searches returning nothing. Above about ten percent and your vocabulary does not match how people talk. Read the actual failed queries; they will tell you which terms are missing in the users’ own words.
- Facet usage distribution. Which facets get clicked. A facet nobody uses should be demoted to a plain field. This is the metric that gives you permission to remove things.
- Term concentration. If ten percent of your terms carry ninety percent of the assets, the vocabulary is too coarse in the middle. If most terms have one asset, it is too fine.
- Time to first useful result. Hard to instrument precisely, easy to observe. Sit with five people, watch them find something, and count the steps. Twenty minutes of observation beats a month of analytics.
Do not do this in a workshop
The most reliable way to build an unusable taxonomy is to design it in a room with the six people who know the material best. They share assumptions the rest of the organisation does not have.
Build the first draft from evidence instead: the search logs you already have, the folder names people actually created, and the words used in the briefs that commissioned the material. Then test it on people who were not in the room, with real retrieval tasks, before it goes anywhere near production.
The taxonomy is not a deliverable, it is a running service. Treating it as a project that finishes is the reason so many of them are dead by year two, which is one of the mechanisms behind why DAM rollouts fail. It also has to survive the state changes described in the asset lifecycle, and it only matters at all because of the argument in what enterprise DAM actually is.