Feature
Often surprising to digital asset management (DAM) newcomers is that it can be easier to lose files inside a DAM than it is to lose files that aren't inside the DAM. Worse, the ways in which your content can become “digitally lost” in a DAM don’t require such notable events as equipment failures, thefts or destruction. This article covers some less obvious DAM considerations that lead to DAM users not being able to find the content they need.
First, let’s define “digitally lost” as referring to a digital asset that is inside the DAM but is not findable. The common search methods and terms users would use to find the asset don’t work. The content, though visible on system reports, is virtually invisible to users.
If you, as a DAM manager, can’t find a specific asset you know is in the DAM, you might do the administrative work needed to recover it. But an asset that is less remarkable -- perhaps one shot from a photo session of hundreds -- can remain digitally lost forever because no one notices it missing from search results.
You might have already guessed that this has something to do with metadata. In fact, it has everything to do with metadata. But maybe not in the way you might think.
Mandatory Field Fights
Enforcers of policy think mandatory metadata fields are great. They reckon that by making a field mandatory, users will always provide the required metadata. You know, the same way drivers always stop at red traffic lights and obey posted speed limits.
In some cases, mandatory fields make sense; but one could also argue that mandatory fields are little more than an uncreative (and possibly most inefficient) way for metadata schema designers to extort values from users. And as we've seen in so many Hollywood torture scenarios, sometimes the poor victim really doesn’t know the required information. Ultimately, they’re killed or they make up some plausible lie just to save their DAM records … uh, I mean their lives.
Do you really need all those mandatory values? Is the value of your DAM lost because certain metadata values are missing? Likely not. It just means that the system could become even more usable once all those values are provided.
And therein lies a more humane solution to the mandatory metadata field: the optional metadata flag. Offer users a means for flagging content that lacks a policy-required value. Let users admit when they don’t know the best answer. Don’t force them to guess or make things up just to be able to save the record.
To make sure things don’t fall through the cracks, use automation to check your system for missing values. Let someone who can provide the best information be the person to provide it. If need be, keep the asset offline until the policy-required values are there.
Mandatory fields discourage users from contributing to their DAMs. They invite users to keep files on local storage, and they do nothing to offer users an honest means for alerting DAM managers when the uploading user is not the best source to provide the required metadata.
In most cases, the actual goal for mandatory metadata fields is DAM integrity, not user punishment. If this describes your use of mandatory fields, consider carefully how this metadata coercion affects your ultimate goal.
If you decide that mandatory fields are the only way, please let me know. You can reach me via my properly formatted, schema-required phone number: (111) 111-1111. You can also try [email protected] because that’s a nice, legal metadata value too.
Bad metadata looks a lot like good metadata. Don’t encourage your users to provide both.
Metadata Fatigue (In Session and Over Time)
Another weapon in the battle against asset “findability” comes in the form of too many metadata fields. As with mandatory fields, this is another example of how a DAM designer’s good intentions can go horribly wrong.
As a design goal, the metadata you track should serve at least one of three purposes:
- Enable users to find content using the means most intuitive to them
- Store a value required for reporting
- Control or route the asset through your pipeline
Metadata values that don’t serve one of these purposes are schema hitchhikers that do little more than distract drivers. If these fields are not made mandatory, no one will populate them; if they are made mandatory, no one will use the DAM. That’s easy math.
As a matter of a Global Rule of Metadata design, make sure your entire metadata schema makes sense to everyone who will use the system. If a field exists, be able to demonstrate how its value benefits your organization today -- not maybe someday.
Another invisible hazard of fatty metadata schema designs comes from user enthusiasm. At first, you might find that users do populate the optional “Mood I Was in When I Uploaded This” metadata field. Over time, though, users learn to ignore metadata fields whose benefits are not clear. This inconsistent application of metadata skews search results and can render some assets digitally lost.
No Easy Reporting Mechanism
Another great way to lose files inside your DAM is to not leverage your best metadata-integrity checkers -- your users.
While using our DAMs, we often notice metadata errors. For example, while searching for “wolf” photos, you might see a photo of an Alaskan Malamute because someone made an understandable tagging error.
What can you do about it? If you lack edit privileges, your only recourse might be to first find out who’s responsible for that asset. Then, get that person’s email address so you can send an email. Wait, first you must go back into the DAM and get the asset link you need for the email. Okay, now email the responsible person. Uh oh -- vacation responder. You email your supervisor who replies, “Can you remind me about this in two weeks?” You set a reminder in Outlook but because the Exchange server is offline for the next hour, you get an error that invites you to try again later.
Learning Opportunities
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
Jun
13
Learn How to Deliver Dynamic Video Experiences at Scale
Learn how to convert existing assets into video experiences in near real-time.
Webinar
Jun
20
3 Steps to Unlock Your Customer Data and Drive Revenue
Discover how Twilio Segment’s #1 Customer Data Platform helps implement data-driven strategies.
Webinar
Jun
21
Retail Reinvented: A Masterclass in Creating Digital Experiences That Click
Hear how online retailers architect their digital experience infrastructure for peak traffic and demand
Webinar
Jun
21
The Feedback Loop: Accelerating Personalization for Exemplary Customer Experiences
Are you ready to harness the power of feedback in your personalization strategy?
Webinar
Jun
22
How to Succeed in Today's Engagement Economy
Doing true personalization at scale with marketing automation
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
Jun
13
Learn How to Deliver Dynamic Video Experiences at Scale
Learn how to convert existing assets into video experiences in near real-time.
Meanwhile, your search session in the DAM has timed out. But this is actually okay becauseyou’ve long since forgotten what you were looking for anyway.
We report errors because we care about the integrity of our DAMs. We report errors because it’s the right thing to do. We report errors because if we don’t, who will?
Of course, unless it’s convenient to do so, we’ll report errors only once.
A “Report Error” field right on the asset can enable users to flag concerns and move on with their work. This is something we’re likely to do more than once.
No Metadata Checkups
Though it might not be feasible to check every asset in your system for metadata integrity, you can perform limited checks. Some of the parameters of those checks could be assets cataloged or edited in the previous seven days, or assets cataloged or edited by new users.
You might even spot check assets that aren’t getting used to see if bad metadata might be the cause. Borrowing from the wolf search example, the Alaskan Malamute photo might be perfectly fine -- it’s just not a wolf. So when wolf seekers find it, they don’t use it. Dog seekers, on the other hand, won’t ever find it, leaving a perfectly fine asset in a state of virtual uselessness.
Worse would be if an unknowing designer does mistake the Alaskan Malamute for a wolf and you don’t discover it until it’s emblazoned across your Macho Fighting League website beneath the headline, “No prisoners; no excuses, no apologies!”
Fetch, Lucy! Fetch! Woof!
Routine quality checks enable you to spot problem trends before they get out of control. You might find that a new freelancer has managed to foil what you thought was a fool-proof metadata editing policy. Or you might realize that two experienced users have different ideas of how the Comments field is to be used.
False Sense of Security
Compounding all of these issues is that once an asset has been put into a DAM, users think the asset is safe. Surely the DAM is backed up, and surely someone else is making sure everything is okay. Conversely, when we save files locally, we pay attention to where we put them and we take note of whether or not our personal data back-up plans will protect those files.
Metadata completeness and integrity are key to not losing digital assets that are inside a DAM. Unfortunately, policy can sometimes make it difficult for users to provide the best metadata, or for them to note when metadata is missing or erroneous.
Don’t design DAMs for perfection. Design DAMs for management and usability. Expect errors and omissions. Users aren’t perfect. (Often, they aren’t even interested.)
But if something we’re asked to do makes sense and is not too difficult, we tend to do it. Let this describe your metadata schema and policy.
Editor's Note: David is no stranger to DAM. Read more in DAM Beauty and Usability
