Resolving The DAM UX Paradox
This special feature has been written by DAM News contributing editor, Ralph Windsor.
Introduction
One area that seems to have got more attention in DAM recently is User Experience (UX). It is instructive to understand what pressures have lead to this becoming a theme as they reveal both a threat and opportunity for the future development of DAM interfaces and consequently the level of adoption and continued use of DAM technology in general.
The Shifting Focus Of DAM
Many of the earlier DAM systems were targeted towards production staff who favoured functional sophistication over ease of use. They needed to be able to adapt the system to a range of different tasks such as orchestration of batch operations. These employees would be using their DAM systems heavily during the course of their working day. Since most were designed to work like classic desktop applications there was an implicit acknowledgement that there would be a learning curve involved, but that it would be rewarded with an improvement in productivity that would justify the effort.
Where the emphasis changed was when a wider range of staff started to need to get assets out of DAM systems. The typical user profile shifted towards larger numbers of infrequent users who maybe access a system a few times a month or less. In conjunction with this trend is increased interest in DAM from marketing communications departments, where hitherto they might have been content to leave this function entirely with production staff.
End User Perceptions And Changing Roles Within DAM
Most ‘normal’ end users, when presented with older production oriented DAM systems, approached them with a mixture of fear and partly justifiable contempt. The original use case for DAM changed at this point and a noticeable divergence in requirements occurred. Production personnel want something that they can integrate closely into their workflow and supports their wider media origination tasks. Casual users see the DAM system as one of many application services they may access ad-hoc as required; they want to be able to quickly find what they want and then leave.
There is an intermediate group that has recently emerged who are positioned between these two opposites who are likely to have some managerial marketing role that still requires them to get hands-on. They will spend longer using the DAM system than casual users, but their range of interactions will be shorter and more infrequent than their production counterparts. So they might be uploading a few assets, approving usage requests or modifying terms in controlled vocabularies etc. This parallels the increased role of marketing in DAM and many of those from this group are users who are not directly involved in production but do still need to manage projects that involve collateral origination.
DAM: Internal Marketing Tool Or Internal Marketing Communications Medium?
Since DAM systems are now used internally on a far more widespread basis, they are now often seen as having a similar role to intranets (albeit with a more specialist digital media orientation). Many DAM systems are viewed as much as examples of internal communications as for their original purely utilitarian role. Not only has the system got to be easy to use, but it has to be properly branded and adhere to a whole series of corporate identity guidelines now too.
The Influence of UX On DAM System Sales
It is clear why UX has been seen to have a greater role to play within DAM. If there are a far wider body of infrequent users and the system itself is now as much about communications as it is functionality, there will be increasing demand for interfaces that are perceived as modern, easy to use and have the ability to more closely represent corporate branding guidelines as would be expected of an intranet or the organisation’s external website.
At one time, having web interfaces that looked like desktop apps used to be a selling point for web based DAM, but that era is long gone. Right now, it means DAM UIs are beginning to looks like fashionable devices such as smartphones and tablet devices with animated front-ends and striking use of colour, visual motifs etc. These methods are employed to persuade more general end users to interact with DAM software and enhance the perception that a system is ‘user-friendly’. Whether it really is or not depends a lot on who the user is and what they want to do with it, however.
By and large, these seem to be successful ways to sell DAM systems. Products that have the requisite ‘glide and slide’ UX seem to be better received than those that do not – an observation made by many DAM vendors too. Not only is it a case of securing the business with the purchasing decision makers, but DAM solutions with these type of interfaces tend to get wider levels of acceptance among the less frequent users because they meet their simpler objectives and offer greater visual appeal.
Having a UI that looks and feels like your iPhone is fine if your typical range of interactions are similar to what you do with that type of device. My experience, however, is that more when you need to carry out more demanding and intensive tasks, mobile interfaces are not flexible enough. While the convenience of being able to do basic work on the road is useful, I will leave more complex jobs until I can get back in front of my regular workstation. There are some vendors who have made a virtue of developing advanced mobile interfaces using tablets etc, but that is not the point I am making. It is less about what device you use than the styles of user interaction which DAM systems are now being designed to support.
Political Conflicts Between Different Groups Of DAM Users And Their UI Implications
The needs of heavy DAM users have been somewhat sidelined in pursuit of increasing overall user volume and this might have consequences unless strategies are devised to address this issue. While older production DAM systems were typically difficult to use, they usually had far better facilities for batch entering metadata and carrying out other large scale asset manipulations.
Those who have some experience of implementing DAM will know that there is an unspoken conflict of interest between the needs of asset searchers and asset suppliers. The former want to find as many relevant assets with good quality cataloguing so they can verify whether the candidate assets really are suitable. The latter want to be able to get the ingestion tasks out of the way as quickly as possible so they can move on to something else. This is analogous to a political debate between those who want ever more extensive public services and others who want lower taxes. Fundamentally, you can’t sustain both for an indefinite period. At different points in time and for various hotly debated reasons, one group has to be favoured over the other.
When I am involved with migration or upgrade projects where existing specialist production oriented databases are being integrated into a single system, a common issue is that while the new solution might appeal to new users, the existing staff find the method of data entry to be more cumbersome and involved than what they had before.
Having wizards and other hand-holding interfaces that guide users through the various cataloguing requirements is useful for infrequent users, but they can be more of a hindrance than a help once the process is understood. This is especially true if you have hundreds or even thousands of assets to deal with on a regular basis.
There are various other options for handling this. One is to provide batch metadata import feature that can load data from an external source like a spreadsheet etc. This is usually available on most DAM systems these days. This is not really solving data entry problem, however, it is more sub-contracting it to another more adaptable but generic solution. A characteristic of production oriented DAM is the interfaces contain a variety of keyboard shortcuts and tools to assist with large scale data entry. The fields might be organised using a spreadsheet-style grid layout to represent multiple assets and there are also controlled fields where the users can pick from pre-defined lists. Of course these options are available on spreadsheets too using macro features etc, but at this point you’re starting to build specialist DAM interfaces in Excel and the task has turned into a workaround exercise to cope with the fact that the system cannot support the needs of the entire body of users.
A further possibility is to offer an ‘advanced’ mode where the wizards and the other embellishments designed to help novices can be set aside . This probably offers the most potential for a long-term solution that will address the needs of high volume asset supplier users, but as you might expect, it is the hardest to deliver also. For DAM vendors that want to provide this, at least two separate interface routes need to be maintained and that number will probably increase as the volume of emerging intermediate DAM users discussed earlier starts to rise also. In other words, everyone wants a UI that is best suited to exactly what they want to do with DAM and there are reasonable productivity arguments to support each case.
As anyone who has some experience of software development will be painfully aware, computer programs usually work great until you let other people use them. Interfaces are one of the harder tasks with software implementation because the users (consciously or otherwise) think up numerous ways to break applications and cause them to fail in ways no one expected or planned for. The only practical way to deal with this is to test them relentlessly using as many kind of obscure combinations of inputs as is feasible. As a tactic, this helps, but it all takes up development and testing staff time (which costs money) and is rarely 100% effective. Adding yet more interfaces into the mix further increases the range of functionality and complexity which exponentially increases the number of points where application can fail and in-turn generates more support and maintenance work. If you had not noticed, there are numerous other priority, must-have feature requests for DAM systems which users are demanding also too.
The DAM UX Paradox
Production staff usually either have access to or originate far more of the digital media that goes on to DAM systems to begin with. Even with large DAM systems in big corporations, I often find that the majority of the material will have been uploaded by a small group of heavy users – sometimes as few as one or two individuals.
One of the other terms that seems to be banded around in DAM circles a lot currently is to refer to ‘silos’ of assets and how these need to be unified and integrated together. It seems to me that this paradoxical situation with DAM interfaces is leading towards more silos rather than less of them.
Many heavy DAM users will tend to treat modern generic corporate marketing DAMs as end-points where they intend to deposit their assets eventually rather than the base for most of their cataloguing work. For photos, they frequently prefer to use something like Lightroom and there are similar examples with other media too. I know from discussions I have had with my co-contributors here at DAM News, other consultants and several vendors that this seems to be quite common.
While modern DAM systems might be good for light-medium use, many are unsatisfactory for the kind of heavy duty volume work that production staff require. The use of a slower web based interface does not help with this situation as even with fast connections and innovations like AJAX etc, responsiveness is still not as sharp as a desktop app. I think that will be a problem that will get solved externally to the DAM industry over time, but a bigger issue is that not enough attention is being devoted towards the needs of the users who will supply most of the assets that users will want to download.
The current UX trends in DAM threaten to constrain the supply of assets and cause more of them to get locked up in private silos because the production users who have access to them have not been given adequate facilities to allow them to ingest assets and manage them effectively at scale. To be clear on the definitions, by ‘ingest’, I am not just talking about uploading a bunch of files, but the whole cataloguing process of applying relevant metadata so that assets can be found when searched for.
Diversity And Interoperability – The Keys To Resolving The DAM UX Paradox
There are vendors who specialise in production oriented DAM systems who understand that there is a need for the ability to industrialise DAM processes so staff can quickly get media distributed to those who need it. While these are good for those staff, they still might not always be suitable for the more recent end users who want simpler interfaces and there is an equivalent risk of going back in the other direction towards products that you need to read a manual to use or be sent on dedicated training courses etc. As I will explain below, the keys to resolving this paradox are diversity and interoperability.
Diversity
There needs to be an acceptance by vendors that they are unlikely to be able to build products that answer all of their end user needs because there is an ever-widening scope of needs based on diverging groups of stakeholders and end users. Once that is acknowledged, it is easier to concentrate on a narrower range of functionality and deliver it more successfully and without dilution of core competencies and niches.
Earlier this month I discussed an article by David Diamond where he unfavourably compared DAM systems with Photoshop. One of the striking differences between Photoshop and DAM software is its clarity of purpose of the former. While Adobe might provide other tools to manage media like video, structured graphics, print media etc, the Photoshop product and associated brand is more or less exclusively dedicated to bitmap images. It is true that it has had a couple of dalliances with other media and some ill-advised functional deviations over the years, but Adobe’s Photoshop development team have not started to jerry-build totally unrelated functionality into the core product and confused their target market in the process. This has happened with DAM and is contributory to why this sector is in the confused state it is now where many prospective end users cannot understand which products (if any) are most suitable for their needs.
If there is an acceptance of this functional diversity and willingness to concentrate products and marketing of them on more tightly defined needs then it becomes easier to develop tools that can address the requirements of a single group of users without needing to hedge your bets and try to appeal to everyone all of the time.
Some of the larger vendors have grasped the underlying fragmenting market trends in DAM and been able to partly solve the diversity issue through acquisition. This is probably an easier option for senior managers and shareholders to accept as compared with getting into bed with the competition. That isn’t a route that is open to their smaller (and poorer) peers, however. Even in the case of the larger players I still don’t think they will be able to continuously buy their way out of the challenge of expanding scope which is faced by everyone involved with DAM.
Interoperability
This seems to be one of these themes in DAM that everyone agrees is a good idea, but very few actually follow through with and fully implement. It goes hand-in-hand with diversity as a method to provide end users with the user experience that matches their objectives for using DAM systems in the first place. If you have a vendor that concentrates on production oriented end users who is able to partner with another provider who can focus on the needs of less frequent users and highly stylised visual interfaces then you can start to realise wider and more diverse product goals that help enhance each other’s offer.
If there is true interoperability between DAM applications this makes it easier for end users themselves to make decisions about how to combine products together so that a production oriented UI can be used to manage a collection of assets while simultaneously a simpler interface can be made available for more casual users.
I am unsure of exactly what or who will provide the standards for this interoperability in DAM. There are various protocols and standards in play currently and some of the larger vendors are developing their own (although no word on whether they plan to open these up for wider use).
If I had to pick a likely technology which might help to realise true interoperability across DAM software, something like XMP might hold the answer as it does allow metadata (which might be workflow oriented as well as cataloguing information) to be held within the asset’s file and avoid the need for a separate exchange of data in addition to the file itself. Even within XMP, however, there is a wide range of potential schemas and complexity in interpreting the information retained.
Conclusion
My expectation is that this will take time to work through across the industry. In the short to medium-term, vendors and buyers of DAM systems will ignore the more intensive requirements of heavy users because of a perceived lack of demand and more vocal requests to make DAM software easier to use (not without some justification it should be noted).
Over time, more employees of organisations will begin to use DAM systems as they become woven into the fabric of the application stack they regularly use, but there will be a falling off in the supply of usable production quality assets because the needs of large scale ingestion will not be adequately addressed. I can foresee a few automated ingestion approaches being used to try to address this, but probably not very successfully as the task is too complicated for mechanised devices like software to do properly and that won’t change for the foreseeable future.
There will be a realisation that despite commitment of a lot of capital expenditure to DAM initiatives, there are even more silos of content than there were before and a mixture of different solutions each required to address simultaneously overlapping and unique end user requirements. There will be a lack of senior management will to invest still further funds into DAM software that has not met expectations and at this point the industry will be forced to properly deal with the interoperability issue in order to sustain itself.
That is the threat. The opportunity is to set the agenda and have more control over how interoperability might be practically achieved. Those on the supply-side of DAM that have got involved at an earlier stage in the process will not only be able to propose methods that are easier for them to implement and require less in the way of alteration to their platforms, but they will also have more time to do it successfully which will give them a commercial advantage to better ensure their survival.
Regular readers of our articles on DAM News might note some parallels with the DAM Value Chain concept (which we rarely miss an opportunity to mention). When I have discussed this with others in the DAM industry and other interested parties, one of the criticisms levelled is that it is a blue-sky idea that stands no chance of ever becoming reality. While it is true we are a long way from anything like that model being fully realised, some analysis of the more direct issues facing the DAM sector right now (like the UX considerations under discussion) clearly indicate that far from a being just a ‘nice to have’ objective, this is an essential stage in the development of DAM that must happen for the industry to survive.
It is unlikely there will be the same level of patience to wait a further 20 years from many of the financial interests positioning themselves behind DAM industry participants now. There is serious money being invested into both DAM products and the vendors who supply them, along with an expectation of a substantial ROI being achieved in both cases. If either party fails to deliver on their promises, there probably won’t be a DAM industry in 20 years, it will have metamorphosed into something else that lacks the same structural constraints which exist now. As active participants in this market who depend on it for our livelihoods, we collectively owe it to ourselves to ensure that does not happen.
About The Author
Ralph Windsor is Project Director at DAM consultants, Daydream and a contributing editor to DAM News.
Website: http://www.daydream.co.uk
Twitter: @daydreamuk
Linked In: http://www.linkedin.com/in/daydream
Share this Article: