Building the backbone
for a brand-led team.
A Brand Hub and DAM foundation build for a UK direct-to-consumer pet nutrition brand. Told through the system, not the name. Explore the architecture, the governance, and the handover.
A brand-led team producing more work, faster, across more channels. The infrastructure had to catch up.
The challenge
The before state
A scaling, brand-led, content-heavy business. Scattered assets across drives and inboxes. Brand drift as more people produce more work. No metadata backbone to make anything findable. A mounting operational load on a team that was capable but under-structured.
Operational drag
Brand drift, version chaos, and no single source of truth.
Scattered requests
Assets arriving via email, Slack, drives, and hallway conversations.
The before state
Scattered files, messy names, no backbone
The approach
Structure with soul
The methodology balances governance and structure with creative usability and human adoption. Five stages, each with a concrete purpose. Click through to see what happened at each step.
Architecture phase · designing the ten-library structure
Understanding the before state
Audited how assets currently live across drives, inboxes, and local folders. Mapped who needs what, where the friction sits, and what an incoming owner would inherit. The goal was not to judge, it was to understand the system as it actually operated.
The system in action
Explore the Brand Hub
This is what the finished foundation looks like in practice. Browse the libraries, filter by group, search by tag, and inspect any asset's metadata. The structure you are clicking through is the real architecture, anonymised.
The deliverable
A Brand Hub the team actually wants to use.
Not a folder structure. A living system that makes the right asset findable in seconds.
Libraries
Filter by group
Interactive mockup · explore the Brand Hub interface, browse libraries, and inspect asset metadata
The architecture
Ten libraries, one backbone
The centrepiece of the build. Ten media libraries, each with a purpose, a group classification, and a metadata schema. This is the real structure, anonymised. Tap any library to explore.
Tap any library to explore its purpose, group, and metadata schema.
Governance by group
Owned versus rights-bearing
Not all assets are governed the same way. Owned assets need consistency and version control. Rights-bearing assets need usage rights, licence expiry, and territory. One system, two governance models. Toggle to see the difference.
Governance
Assets the brand creates and owns
Brand-owned assets: logos, fonts, palettes, devices, illustrations, packaging, icons.
Governance focuses on consistency, version control, and correct usage.
No external rights tracking needed. The brand controls the asset entirely.
Metadata is about findability and correct application, not legal constraints.
Schema differences
Owned libraries focus on type, variant, and usage context. No rights or licence fields.
The backbone
Metadata as infrastructure
Metadata is what decides whether a DAM scales or collapses. A small set of mandatory global fields, a controlled vocabulary, and a clear line between required and optional. Try tagging a sample asset to see how discoverability works.
Controlled vocabulary · every field justified, every value deliberate
The principle
A small set of mandatory global fields
Every library, regardless of group, carries the same backbone. A controlled vocabulary, required versus optional, applied consistently. This is what makes the system scale.
Every asset has a structured, searchable name.
Plain-language context for what the asset is and where it lives.
Controlled vocabulary. Not free text. Findability depends on it.
Auto-captured. The timeline of the system.
A named person accountable for the asset. Not a team, a person.
Try it
Tag a sample asset
See how metadata makes an asset discoverable. Tap to apply the schema to a placeholder image.
2503_Image_Campaign_Spring
Image library · Group B (rights-bearing)
Governance and handover
A build is only as good as its handover
The artifacts that made this adoptable. Not a folder of files, a structured handover designed for an incoming owner to pick up and run with.
Handover document
The full picture: what was built, why, and how it fits together. Written for the incoming owner, not for us.
Run-sheet
A practical, step-by-step guide to operating the system day to day. Not theory, the actual moves.
Async handover message
A recorded message walking the owner through the build. Context that survives staff turnover.
Visual section maps
Diagrams of each library and its structure. The owner can see the architecture at a glance.
Outcomes
What phase 1 delivered
- ✓
Ten media libraries with collections and baseline settings
- ✓
Group A / B split with governance tuned to each
- ✓
Per-library metadata schemas against the build guide
- ✓
Library descriptions and structure documentation
- ✓
Metadata audit across all ten libraries
- ✓
Structured handover: document, run-sheet, async message, visual maps
- →
Asset population across all libraries
- →
Brand Guidelines build on the Brand Hub
- →
Rights and licensing review for Group B assets
- →
Public go-live at a later date
Assets awaiting migration are marked migrate-finals-later, not archived.
What made it different
The Artisan Systems difference
Architect, not administrator
The work was senior consultant capacity, not project management. The thinking that shaped the system is documented, not just the tasks that built it.
Governance balanced with creative usability
A DAM that is too governed goes unused. A DAM that is too loose collapses. The structure serves the people who use it, not the other way round.
Documentation clear enough to hand over
The handover was the deliverable, not an afterthought. An incoming owner can pick up the system and run with it without reverse-engineering the decisions.