Usability And User Experience In DAM
One of our featured DAM Vendors, Brandworkz, have contributed a featured article for us: DAM Good? Yes, It Can Be! – How To Make Users Love Your Digital Asset Management System. The item was written by Neil Monahan, their Digital Marketing Manager and describes the importance of making DAM implementations both easy to use and attractive:
“It cannot be stressed too strongly: an intuitive interface, simplicity of use and an agreeable user experience are the foremost characteristics of any truly effective digital asset management system. Which brings us to the bottom line: if the DAM system isn’t easy to use, people won’t give it the time of day. And where would that leave a company’s return on investment?” [Read More]
There is not much you can argue with in the article and it is solid advice for anyone implementing DAM.
As ever with DAM News, however, we can’t pass up any opportunity to be contrary and point out some ‘nuances’ which make the undertaking rather less straightforward than it ought to be. These do not detract from Neil’s points (which I fully agree with) but they need to be considered alongside them, especially if you are in the process of refreshing an existing DAM solution rather than from scratch without anything having been in place before (as a lot of people are now).
Although the usability of the application is clearly critical to generating ROI, I have found that when referring to ‘the client’, although this might give the impression of being a single entity, in fact it is composed of multiple stakeholders (some of whom may share little more than a logo in common with each other). Whoever controls the budget obviously has the trump card, but even within that group, personnel or business changes can reset the priorities over the course of the system’s lifecycle. The benchmark I work to is normally 5-8 years for most enterprise DAM systems and that appears to be consistent with what others have mentioned to me also. Think back to what you were doing 5-8 years ago. For myself, in terms of professional activities (and a few personal ones) that’s like light years of time and a multitude of change-events along the way.
These ever changing circumstances are the biggest source of complexity when dealing with usability in DAM systems (and probably software in general). Usually when a system is first released, even if it’s a second or third generation implementation, the UI will be considered a clean sheet of paper exercise and (as Neil says) a lot of the extraneous noise will get cut away, often because the people who asked for it to be included have long since left the business, got promoted or are otherwise out of the picture. After a period of using the system, additional functionality will be required and depending on the capacity of the interface design to accommodate these modifications, the clutter may begin to return. This has to be continuously reviewed and every pixel of the UI required to justify how exactly it is paying its share of the rent.
An issue I have found with multiple stakeholder solutions, especially for very large companies is that to accommodate conflicting requirements, the complexity has to ramp up and some compromises get made. Vendors don’t like talking about these, but you can guarantee that all of them who have worked on more than a few solutions for clients of a reasonable size will have run into them and been obliged to implement something that is not wholly satisfactory, but which does keep most of the people no worse than mildly irritated, most of the time. This is the politics of enterprise DAM user interfaces in action. Neil makes some reference to a few of the people this can become an issue with here:
“And then there are the heavy system users. Typically these are the people who populate the system and maintain it on a day-to-day basis. They’re the technical folk. They will want to get ingestion and maintenance tasks done as quickly and accurately as possible – for example bulk uploading, adding metadata, moving assets and files, creating new folders or setting up new user groups.” [Read More]
In my experience, there are often more than heavy users to consider and you may require an entire pie chart of user segments to consider. They may not always neatly sub-divide into those permissions groups that your DAM system of choice probably allows you to define. Frequently, they can cover quite a diverse range of personnel who only have a transient relationship with each other in terms of their requirements (which will further frustrate the segmentation analysis you must carry out to identify them).
An item of advice I would offer is to count on the interface changing and that as well as the resistance to introducing the DAM, expect further complaints when you try to change it to support the needs of one particular group of users. Interfaces for large DAM systems often seem like managing car parks full of problems: when you move one around, you will have to make other modifications as a result. I follow Neil’s point about making it look good, but you also need to carry out an analysis of the implications of any changes. Assessing how and where these might come can never be 100% effective, but it might avoid some major pitfall that negatively impacts ROI. In so far as you have the capacity to be one step ahead, you should always try to be.
Lastly, on the point about having an attractive interface, I would not disagree, but there are some risks to guard against. The driving force behind making DAM systems look more compelling than the Windows 95 faux-desktop app style that was in vogue a decade or so ago is undoubtedly the interest in DAM from marketing departments. It almost goes almost without saying that whatever system gets released under marketing’s banner must fully reflect the brand guidelines of the business because otherwise end users will call into question how serious they are about enforcing them in other contexts. However, I have seen more than a few DAM solutions where the funky ‘glide and slide’ UI has acted like a diversionary tactic to take attention away from some major flaw in the interface itself, especially with reference to scalability. For example, systems that look great with 3-4 search results and then transform into the proverbial dog’s breakfast with 5,000 thumbnails of you firm’s product datasheets (or whatever similar corporate marcomms collateral you generate).
It is important to reality check how the system will be used over a longer duration and what elements of the interface are going to see the most action. Just as most families with small children tend not to fit their houses out with wall-to-wall white carpets and lots of fragile porcelain ornaments, so you need to think about the pressure points with your DAM and what kind of spills and hazards might occur when the vendor has handed the keys over to you. Fundamentally, the DAM system is a productivity tool, if it looks great but does not deliver on that objective then it is just a very expensive and pointless internal communications exercise.
This is a good article from Neil. As a DAM user, you need to take his advice and think about how to practically apply to your situation over the full duration the system will remain in use in order to get the most out of the investment of time and money you plan to make into implementing and maintaining it.
Share this Article: