DAM Taxonomy: A Practical Guide

Most DAM platforms launch with a taxonomy that almost nobody uses. The categories read sensibly on a whiteboard, the hierarchy is logically sound — and yet six months in, people are searching by keyword and ignoring the tree entirely.

The usual cause: the taxonomy was designed around how the collection was stored, not how users actually look for things. A good DAM taxonomy is a navigation tool, not a filing cabinet. This guide covers what a taxonomy is in a DAM context, the different shapes it can take, and how to design one that survives contact with real users.

What DAM taxonomy is (and what it isn’t)

Taxonomy, in DAM, is the classification scheme that organises digital assets into navigable groups. It’s the structure users move through to browse, filter, and discover.

It’s easy to confuse with metadata, because the two are tightly related. The simplest distinction: metadata describes an individual asset (creator, date, file type, licence, keywords). Taxonomy describes the categories assets belong to (Campaigns > 2026 > Spring, or Collection > Archaeology > Bronze Age). Metadata answers “what is this asset?”; taxonomy answers “where does it sit, and what else is near it?”

In practice they work together. A taxonomy branch is only as useful as the metadata that feeds into it, and metadata becomes navigable when the taxonomy makes sense of it. Together, they’re what makes a collection findable, accessible, interoperable, and reusable — the FAIR principles that shape most modern DAM strategy. Metadata standards such as Dublin Core give a starting vocabulary; taxonomy gives it shape.

Types of DAM taxonomy

There isn’t one correct shape. Different collections and different user needs call for different approaches.

Hierarchical (tree). The traditional form: parent categories with child categories nested inside. Good for collections with natural hierarchy — archaeological periods, corporate divisions, geographic regions. The risk is rigidity: hierarchies are painful to restructure, and assets often belong in more than one branch.

Flat / tag-based. No hierarchy, just a controlled list of tags applied to assets. Simple, flexible, and fast to set up — but it loses the sense of place and structure, and large collections can become hard to browse.

Faceted. Multiple independent axes — by subject, by date, by format, by campaign — that users combine to narrow a result set. This is the dominant model for modern digital discovery (think Amazon filters, or museum collection sites). Faceted taxonomy scales well and mirrors how people actually search.

Polyhierarchical. A hybrid where a single asset can live in multiple places in the tree. Useful when categories genuinely overlap — a photograph might be relevant to both “Events” and “Brand Campaigns”. More complex to maintain, but avoids forcing unnatural choices.

Most modern DAM platforms support a combination, with a primary taxonomy tree for navigation and facets layered on top for filtering.

How to design a DAM taxonomy that gets used

The core principle: start from how users look for things, not from how the collection is organised.

Interview your users before you draw a tree. Ask the people who’ll actually browse the DAM what they search for in a typical week. The categories that come up repeatedly in those conversations are your top-level branches — not the ones that seem logical on paper.

Keep the hierarchy shallow. Three or four levels is usually plenty. Anything deeper and users stop drilling; they jump to keyword search instead. If a branch feels necessary but deep, consider whether it’s really a facet in disguise.

Use mutually exclusive categories where possible. If an asset could reasonably go in two branches, users will look in the wrong one half the time. Exclusivity isn’t always possible — hence polyhierarchy and facets — but pursue it as a default.

Plan for growth. A taxonomy that’s perfectly tuned for today’s collection will creak under three years of new assets. Leave deliberate space for branches you don’t need yet, and review the whole thing annually.

Align labels with how users actually speak. The term that makes sense to an archivist isn’t always the term users type into a search box. A curator might call a branch “oral history recordings”, but staff looking for a clip will search for “interview”. Either adopt the language users already use, or invest in a controlled vocabulary of synonyms that maps common variants to the right branch. Taxonomy that ignores user language forces every search through a mental translation step, and many users won’t bother.

Decide who owns it. A taxonomy without an owner drifts. Name a person or small group responsible for approving new branches, retiring stale ones, and resolving disagreements when categories overlap. Governance is rarely glamorous, but it’s what separates a taxonomy that stays coherent at year three from one that has quietly fragmented into competing conventions.

Think about how taxonomy feeds search. In a good DAM, the taxonomy directly informs faceted search and security rules. Designing taxonomy in isolation from search behaviour usually produces something ornamental rather than useful.

Common mistakes

Designing in isolation. The single biggest failure mode. A taxonomy built by one archivist (or worse, by committee) without user input rarely survives first contact with the people meant to use it.

Deep trees that look comprehensive. A seven-level hierarchy with 400 leaf nodes looks impressively thorough. It almost certainly won’t get used past level three.

Overlapping categories. “Marketing” and “Campaigns” sitting as siblings at the same level means every asset is a judgement call. Merge, subordinate one to the other, or move to facets.

Never revisiting. A taxonomy that’s fit for purpose at launch can drift quickly. If you don’t have an annual review in the diary, you don’t have a maintained taxonomy.

How Aetopia implements taxonomy

Aetopia’s DAM combines a global taxonomy tree with a configurable metadata system, so collection managers can model very different requirements within the same platform. The metadata system has four main building blocks:

Taxonomy. The global taxonomy tree acts as the classification scheme, linking metadata together and underpinning other features including faceted search and the security model.

Metadata fields. Defined centrally in any of the supported field types — text, tags, dates, keywords, lists, large hierarchies. Fields can have validation and display rules, so they only appear when needed and the data entered is properly vetted.

Metadata groups. Fields can be organised into groups and, optionally, pages and views. Administrators can restrict visibility of a group to named roles for sensitive information, while leaving other groups visible to everyone. Visibility rules apply at the group level, so sensitive fields should be grouped together where possible.

Metadata views. A higher-level collection that can contain both fields and groups. A single field can be defined once and reused across different views and contexts — a lot of flexibility for comparatively little setup.

Once configured, the metadata is presented to users when they select an asset, with the image on the left and metadata editing on the right.

Taxonomy is the difference between a DAM and a graveyard

A well-designed taxonomy is the difference between a DAM people actually use and one that quietly becomes an expensive archive. It’s worth the thinking time up front, and the annual review once in place.

If you’re in the middle of designing one and want a second pair of eyes — or if your existing DAM’s classification has drifted and you need to tidy it up — we’d love to help. Reach out here.