When one compares the user experience of something like Mail Chimp to digital asset management software, it’s easy to see why people complain that DAM software can be cumbersome to use.

And while DAM vendors scramble to repaint their UIs and, in at least a few cases, turn their backs on their legacy apps in favor of flavor-of-the-month “DAM Lite” variants, it’s clear that DAM vendors might not really understand the problem. The issue isn’t that DAMs are ugly, the issue is that the very paradigm upon which we’ve built these systems has become obsolete and, therefore, cumbersome.

A Little Too Far Off the Beaten Track

No matter how pretty the UI, a DAM remains a place people must go to get what they need. We place digital assets in a repository that is almost certainly not where we are when we actually need those assets.

A quick visit to the DAM might seem reasonable but actually it’s not. Not long ago -- and in some parts of the world still -- if you wanted water, you had to visit a well. Today, we have faucets. Even better, we have faucets throughout our houses, each located where the need for water is expected most -- at the point of consumption. When we leave our houses, we also find faucets at work and virtually wherever else we go.

Imagine how different life would be if every time you left the house, you had to take with you the water you’d expect to use throughout the day for drinking, washing and flushing.

Through the advent of plumbing, we discovered that by delivering water to the point of consumption, we could change the world. Better yet, by ensuring that all faucets worked in pretty much the same way, they could be used without training. (Unless you’re an American in a European hotel room.)

This is the paradigm upon which the next generation of DAM must be built. We want digital asset access, not from some random website location, but from within our apps and anywhere else we happen to be -- Google plus, a Disqus comments thread, Facebook, Twitter, etc. We don’t want to go to a DAM well to get what we need, and we certainly don’t want to have to learn a bunch of UIs that vary with each consumption point.

But this is exactly what today’s DAMs have been bred to be. Rather than part of the infrastructure, DAMs are pieces of furniture. They sit above the core of what makes a business a business and they’re ultimately expendable. What we see going on now, as ever more vendors claim to have the most beautiful or user-friendly DAM system, is not a reinvention of that failing paradigm; we’re seeing DAM vendors reupholster DAM software to hide its Avocado Green and Harvest Gold origins.

The DAM News team’s Ralph Windsor has suggested that DAM vendors are running low on ideas or that we’ve perhaps slammed into the limits of what we know how to do. I say he’s correct, particularly on that second part. DAM evolution has stagnated because we’ve slammed into the limits of this asset-from-a-well paradigm. Unfortunately, no DAM vendor has stepped forward to introduce a true alternative, and that’s where Ralph is correct on his first point.

And I think we’re all starting to realize it.

Integration Salvation

There is evidence that DAM vendors understand what’s going on. The flurry of DAM integration announcements we’ve seen in the past few years suggests that vendors have discovered life outside the DAM ghetto. Vendors are plugging DAMs into everything, and then displaying those product logos on websites, like they’re the stuffed heads of game conquered bare-handed. (It’s like we've traded taxonomy for taxidermy.)

This is a step toward point-of-consumption asset access but there is still one problem: each DAM integration is different. In some cases, the differences are forced by API limitations, leaving integration developers with limited options. But I think that in most cases, the problem is simply that integration developers are lazy -- and this includes DAM vendors who create their own. Rather than see each integration as another road leading to the Rome called DAM, they think “press release” first and they think “user experience” … well, maybe in the 2.0 version. You know, if enough copies sell.