Setting up a company DAMS

I recently helped pick and project-manage a Digital Asset Management System (DAMS) to house all of the photography (and other assets) for Britain’s largest student accommodation provider, Unite Students. Here’s a breakdown of what was involved.

DAMS dashboard

Business need/requirements

We had problems with our folder structures; basically they were so convoluted nobody could find photography, images were regularly duplicated, deleted and their usage was never properly regulated. At Unite we also had city (property) teams who needed quick access to print template text which they could easily edit without the need to learn or maintain software. Another concern – highlighted with the advent of GDPR legislation – all models would need a signed “release form” attached to them, something we did not necessarily have.

At it’s core a DAMS is a storage tool for uploading assets, and most look similar to stock photography websites like iStock or Bigstock. It would allow us to regulate the usage of photography and other assets with user permissions, search, filter and group similar assets. It would also mean we could widely stop the duplication of assets.

The need for a DAMS was hard to define in terms of cost-saving benefits, which is often make-or-break for the company. We knew we would save time and as a consequence, money from spending less time searching for images and requests to the design team. We also knew we’d benefit in countless other ways.

 

Having determined our most important needs, we could move onto the next step.

 

Research, demos and comparing systems

I spent a lot of time reading materials and white papers to determine all of the features we’d need from a DAMS that would tally with our wish list. I also spent time demoing systems online, reading reviews and watching testimonial videos.

 

We sent a brief out to 10 DAMS providers and waited on responses. From this, we narrowed it down to three systems. We had these top three come to our offices to pitch, demo and talk costs, and selected based on this.

 

Chosen DAMS, Pitch, Kick-off (with key stakeholders)

Once we had chosen a system we had a kick-off session with the provider and started to talk about categorisation (taxonomy) of the different types of assets we would want to upload. In addition to photography we would want a space to store brand assets such as logos, and videos, etc.

 

Off the back of this we collected sample assets from teams we worked with, and I spent time testing various taxonomy uploading different assets and scenarios.

 

Taxonomy/filtering

Perfecting the taxonomy means that searching and filtering becomes easier for the end user and can make or break the system from a usability standpoint. It’s a fine line between too many filter options and not enough. Here are some considerations:

  • I assembled lists including university and our property names, all of the possible areas within properties (eg common rooms, study rooms, corridors, etc), and room types (several variations), so I could then filter based on these
  • Fields like the “Usage rights description” (text field) only appear when “usage restrictions” under “terms of use” is populated
  • Tags
  • The option to add in a signed model release form only appears for users with more permissions, and cannot be viewed by anyone other than an admin
  • What data type should fields be? E.g. what should be a drop down, what should be a free text field, etc
  • Selecting the filter “Photography” reveals a sub-asset type inc. “Products”, “Accommodation” and “Buildings, etc

DAMS filtering and taxonomy

DAMS asset detail

User cases

Defining user roles was as much an exercise in learning the system and what settings meant as deciding who should be able to do what. Luckily I’d already created the criteria, which was half the battle. I’d say on initial setup we’d got about 90% of the heavy lifting done, and then it was a case of tweaking the different user types through logging into different accounts and testing their permissions individually.

 

I defined the following users:

  • Admins (myself, and potentially one other – dictated by licenses in our package). You can set up admin accounts typically to enable you to create users, taxonomy, and define who and who can’t sign off workflow templates, etc
  • Heavy users – almost admins, but unable to change things like user and system settings
  • Lite user type 1 – city team users who could only access the templates section to run off posters and change simple text e.g. times and locations
  • Lite user type 2 – in-house users, who can just access and download assets in the bank of images
  • External Photographers/agencies – this user type would simply use a WeTransfer-esque express upload form and upload to the system that way. They would not need their own accounts

 

Inevitably a few things would change an evolve based on real-world scenarios only detected after launch.

 

On giving and taking away features/permissions for live users there are two schools of thought:

  • Give people more to begin with and take it away if they don’t need it
  • Give people less to begin with and give it if they need it

There are pros and cons of each, one of the main issues being that if you give them everything and start taking things away, they will likely get annoyed and perhaps even give in on a system that relies completely on their buy-in to succeed.

Excluding features could mean anything from showing and hiding relevant sections on the dashboard once logged in, hiding the “media” section (the hub of all image uploads), to disabling the ability to edit system settings (in our case, the admin permission only).

DAMS login screen

Tracking the project

I managed the project through Trello, inviting members of the DAMS provider to the board, which was a great reference for catch-up calls.

Using Trello for DAMS project

Admin

I feel a little bit uneasy titling this section “Admin” as in “all of the other stuff”, but it’ll have to do. Of course, the things that make up this section were important, but generally easier to pull off than the other headlines I’ve included:

 

  • Naming the DAMS – naming the system was important for stakeholder buy-in. Should it just stay as the name of the provider? Should we label it, brand it even? Important questions.
  • Support/Shared inbox – again, what did we want the support email name to be?
  • Single sign-on – a techie thing, but a decision to be made. Did we want a separate login for the system, or the same login staff use to get onto their machines? This would mean their account deactivates when they leave the company, without another set of credentials to remember to deactivate
  • Branding – As an (initially) off-the-shelf system in the cloud, we required some of our branding, including bespoke styling, our colour palette, logos and photography for banners and cards, etc
  • Analytics/reportage – Getting Google set up on the system initially in addition to any reportage tools used on the system itself. This would be used to garner intelligence as to how much imagery has been used, what has been overused/we need more of, restrictions (e.g. auto-archive photos after a certain date; fashion may change and usage rights may expire)
  • Branding section
  • watermarking
  • Regular catch-up calls – to get all of this done on time, regular catch up calls were scheduled, often referencing cards on Trello

 

Legal documents

I had to work with the legal teams to create and evolve terms of using the system, usage guidelines, and the systems cookies policy.

DAMS privacy policy

Model release forms

Another set of chats with the legal team to re-write and bolster our permission forms (see my photography case study for more detail on how these were developed)

 

Bugs/learning “train the trainers”

In a series of training sessions I and my colleagues were trained up in using the DAMS with the idea that we would later train relevant stakeholders around the business. These consisted of things like how to define taxonomy, editing user permissions, how to define workflow and setting up publish-on-demand templates. The sessions were designed to be quick run-throughs of possibilities before we would go and test and learn in our own time. We had several catch-up calls in-between these sessions, and I was the primary contact with the most training.

 

Training stakeholders/soft launch

A few weeks after being trained I scheduled in training for my stakeholders and colleagues, and then allowed them to use and upload to the system; to sense-check everything had been set up correctly (including the taxonomy and workflow features).

 

Bug fixes and full launch

Creases ironed out, we launched the DAMS to the company, and now it is used within the head office and also in student accommodation properties around the UK to produce print materials.

The whole process took a few months, including time for senior stakeholders with buying-power to be convinced by the system. The process got easier as time went on and the DAMS is already helping the company immensely from a time and accuracy standpoint alone.