What a DAM Mess

“Hey, Paul, you and your team know information architecture. Ever work with Adobe Assets?”

That’s how it started, humbly and simply, with a question from a business development lead at my agency. He had been working on a few deals that included Adobe Assets, one of the popular Digital Asset Managers – or DAMs – out in the market. I answered to that colleague, simply, “Not yet, but I’ll look into it.”

Digital Asset Management – also DAM – holds the promise of centralizing all of an organization’s assets… things such as images, content, PDFs, working files, and so forth. It was something that I had a basic familiarity with at the time, but once I learned more, I recognized how powerful a centralized set of assets would be for just about any organization.

While standalone DAMs exist, integration with a broader Content Management System (CMS) or Digital Experience Platform (DXP) is where the real power comes into play. An example of that promise is: I can have an asset that is on a content maintenance cycle, well-tagged, in a folder and place that makes sense in a DAM… that can then be associated with a particular component or template in a CMS… that can be measured for performance in a test-and-learn personalization program, and adjusted accordingly. It’s the end-to-end “Hey, how is this doing?” question that any marketer worth their salt has.

Many DAMs offer significant integration points beyond that (extending this into broader organization workflow management, and existing creative tools) but that’s the gist of it. Organize your stuff, maintain it, and you’re setting yourself up for a bright future of serving up totally personalized experiences to customers on their phones, tablets, computers, watches… you name it.

Well. Maybe.

Where do we put our DAM stuff?

I started working with my team to understand how information architecture (IA) could or should play a role in the DAM work we were selling.

The start of untangling any mess – as information architecture (IA) expert Abby Covert might suggest – is understanding what you’ve got. An inventory and audit, addressing both qualitative and quantitative aspects of content, is the start of so so much work. And in working with DAMs, by delightful coincidence, starting with an inventory and audit makes a ton of sense.

This is where organizations start to get wide-eyed and realize how much of a challenge moving to a new DAM (or simply organizing their assets) can be. When I worked with a large-scale retailer several years ago, we opened a discovery by talking about where they stored their assets today. Great news: they had a shared creative server, internally!

But the creative team also regularly dropped things on their local computers – desktops were full of icons. They also had another shared server for some production assets. And a SharePoint instance where some things lived. And they also used Box for a few things. One marketing team had a totally different process. Yet another department had designed a full lifecycle process built around catalog production that worked well for them, but isolated all of their work from everyone else.

Inefficient? Don’t be so sure. These teams all still produced displays, catalogs, digital ads, 4 websites in 2 languages, and more on a seasonal basis. That’s not trivial work and they got it done, every time.

But they recognized that having a centralized library of all of their work could lead to efficiencies, both in organization and processes around content and asset production. Did they need to have an asset from a photo shoot in 24 different places? No. Did they need to manually create contact sheets in PDFs for approval by creative directors? Also no. Did they need to manually create variations of an asset for display ads, the website, and the mobile website? No!

This is all to say that the way most organizations handle assets today is likely very, very inefficient from a broader enterprise perspective, even when everything happens on deadline and on time.

Enter the IA

That brings me back to the question posed by my colleague. Organizing a DAM is all about figuring out where to put things, how to name things, how to not name things, how to account for modalities, how to support various users’ needs, and almost everything else in a space I typically define as information architecture.

What I’d seen anecdotally at that agency and elsewhere was that developers would handle everything about assets because it was seen as a development task. And while developers absolutely incorporated a degree of IA in their work, it was usually the “best practices” that had been used elsewhere. Anything else around deeply investigating relationships between these pieces of information was left to the client. It felt like a real opportunity.

This isn’t where I’ll say an IA came in and was a superhero and resolved it all. But it’s important to note that with a dedicated information architect involved in the process early on, the shape of the work got a little different.

We started to apply information architecture principles and heuristics to DAMs. In the work my team does now, once we complete the audit, we review it fully with the client in a workshop setting. We talk through how things are organized, any peculiarities, and definitely add in a lot of “nice job on this!” too.

From there we start to analyze their organizational structure and workflows to inform the folder structure. In my experience a DAM is one place where an organization’s structure internally (teams, departments) can make sense for where to put things. But even talking through and reviewing how work gets done in a collaborative, workshop setting is essential.

And while workflows lead into a richer, more governance-related bent of this work, I’ve found that many organizations haven’t taken the time to simply write down, step-by-step, how they do things. These aren’t small companies, either. These are monsters. Big ones. And them seeing things like, “Oh, wow, this gets approvals from 8 people in email” and “Huh, this department puts their stuff here but it really should be there, maybe” is revelatory.

And yes, the development team is naturally involved in this work. They're getting a front row seat to the blueprint for a migration and setup of a DAM.

Ultimately we deliver a full set of recommendations on folder structure, taxonomy, tags, metadata, and naming conventions. We typically include workflow analysis and recommendations too. This culminates in a framework for these teams to take and run with as they look to reorganize, migrate, and implement a new organizational system. Not small work, but important work.

The DAM of the DAM

There’s a slight cautionary tone in my words here, because one other risk I typically see is assigning ownership of the DAM to an already-busy marketing team, an IT team, or a creative team.

I’m not here to tell you if you should reorganize your team but I will say: you absolutely, positively, 100% need to make it someone’s job to be the Digital Asset Manager (DAM) of the DAM. They may be an Asset Librarian, a DesignOps expert, an Information Architect, whatever. Critically that person needs to have knowledge in information architecture. They may “live” in an IT team or marketing team, but having knowledge – at least from a business perspective – of the particular DAM being used is immensely helpful.

The cover of Murmur. DAM kudzu.

When I’ve worked with clients who have internal DAM owners, things are different. The discussion becomes more about how they can scale and grow a system for a team, and how they can enforce standards. The discussion includes not just the immediate work but what’s around the corner: governance, ownership, and maintenance, critical parts of digital work.

Without DAM owners? Well, you know the cover of R.E.M.’s 1983 Murmur, right? The kudzu? That’s what happens to the DAM. One department organizes things one way, another doesn’t tag anything, and soon you’re back in the same place you started. Not having a person in charge of DAM governance is a pretty bad idea.

Change is DAM Hard

Centralizing your assets is all about change. The way things worked may stay the same, but how things are set up is going to be new. And change is hard. I’m starting to say this more and more: all of this will lead to people being pissed off, upset, or discouraged.

Some people get very attached to their way of working and don’t want to change it. This isn’t something that shows up on a DAM feature scorecard, but you have to honestly and openly evaluate how ready your team is to change. It is absolutely a factor in moving to a different DAM, or any DAM, and absolutely should be considered. I’ve joked that workshops are like therapy but, sometimes, they end up leaning hard in that direction for just this reason. Don’t forget the emotional work, either.

IA is Essential

That simple question that came my way years ago led to a lot of good work with people and teams to figure out how they should better organize their stuff. So when you’re evaluating your DAM – either a current one or shopping for a new one – do not overlook the importance of information architecture. It’s DAM important.