The UX Asset Management Challenge

When multiple designers work on multiple assets or across multiple projects, it gets very difficult to manage files over time. Which files are the latest versions? Which files are even relevant any more? Which files contain things that may be affected by the contents of other files? Yet with a few short-term exceptions, I have yet to see any reliable method of version control and general asset management in use in either agency or in-house digital product design environments. File system layouts, wikis, SharePoint sites, piggy-backing on Perforce or Subversion installations, git hub, DropBox, and numerous other hacks notwithstanding.

There are now quite a few systems aimed at designers that attempt to solve the issues. Have a look at Timeline, for instance – an SVN-based method of managing shared Adobe documents. I’ve not used it myself, but I’m sure it’s great at making sure different people don’t stomp on each other’s work by mistake, and does a nice job of keeping track of different versions. Design is not an activity that progresses linearly, and having easy access to past iterations is useful. The same is probably true of Adobe Drive and Alien Brain, neither of which I have used – nor have I heard of them being used by any design operation in the UK or elsewhere.

So why do design departments choose to wallow in chaos rather use systems such as developers do? Perhaps it’s because all such systems are only as good as the discipline that people bring to them. For example, the above solutions each assume that everyone will use a single agreed file all the time (eg “home_page.psd”, “sprites.png”).

But in UX design practice, it appears to be human nature to re-name and make copies of files for various reasons (“home_page_v2.psd”, “homepage_FINAL.psd” etc.). In the world of software development, doing this has immediate consequences to the integrity of the application being built. A developer re-naming a file is therefore a comparatively rare event that has to be properly thought out or the application may not run.

Perhaps because all version control systems have at least their roots in the world of software development, none of them prevent designers from casually adding and re-naming files in the way designers like to do when they work. Yet this instantly and completely destroys any integrity the system has, while having no immediate impact on the designers that do it. No impact, that is, until later when they try to work out why a file called “home_page_FINAL.psd” is older than one called “home_page_v5a.psd”.

So the minute that happens, there’s hardly any point in having an asset management system in place. Remember too that the other main advantage of such systems for developers is diff and merge, which for obvious reasons are not viable for things like Photoshop or PowerPoint files.

But even if you can persuade people to abandon their compulsion to create new files rather than continue to work on existing ones, there remains a deeper problem.

It is remarkably difficult to agree on what files should be subject to version control in the first place. Should “home_page.psd” exist, or should it be several files (“header.psd”, “footer.psd”, “masthead.psd” etc.)? Modularising it like this might be a better way of treating the home page assets if different projects are running at different times that affect it in different ways. And what should you do about multi-variate tests that are currently in progress?

Combine this with the frankly rather amazing fact that the Adobe Suite (save Fireworks to an extent) doesn’t support dynamic object linking between files, and you have the characteristic design process chaos that I spent  a good chunk of my time at hotels.com trying to do something about.

When everyone is heads-down “delivering”, it’s amazing how much inconsistency, error, lost work and related difficulty results from just wrangling assets of various kinds. Chuck in short-term freelancers, multiple methods of exchanging files (“Have you used AirDrop? It’s so cool!”), the phenomenon of projects going “on hold”, and various other things. Asset management is perhaps one of the NP-hard problems of the UX design process.

But this isn’t to say that asset management for design teams is an impossible dream. Rather, I think it needs everyone using the system to be a lot more familiar with both its use and the wider, “softer” issues around it than is often assumed. These wider issues also need to be considered when evaluating any potential software to use. For example, having a permissions model of some kind would certainly help.

Now that I’ve moved to MailOnline, I may get another opportunity to look at this some more I think.