When designing the structure and taxonomy of your Asset Bank, unfortunately, there is no silver bullet - every implementation is unique and there are always customisations you can make to optimise the user experience.

It is worth considering your users first - who are the key users? What assets do they use the most?  What search terms are likely to be most important to them? By considering the perspective of your users throughout the configuration then it will help to ensure the end result is functional and easy-to-use.

There are a few key areas that we normally walk through in order to get a baseline structure for the system: Folders, Attributes and Groups.

Structuring your Asset Bank

The easier it is for your users to find the assets they are looking for, the more effective your system will be. The most common way that users will find assets is to browse through your Folder hierarchy, navigating the sub-folders to find the asset(s) they are looking for. Often, even if using search options, selecting the relevant folders is a key way of narrowing down your search results in order to find the correct asset.

Having an effective structure with descriptive Folder names is important as this text is also used during search queries - this means that if, for example, your asset is already in a Folder called "Stock photography" then you don't need a separate Attribute that specifies whether the image is owner or stock as this would be duplicated information. Reducing this duplication makes the system much easier for people uploading assets to your system as the process will be much faster and less frustrating.

Determining your Folder structure

Folders are particularly important as they form the basic structure to store your assets. Folders are also used to control your permissions, as users may have different access on a folder-by-folder basis. Sub-folders can also have unique permission if you need to segregate certain assets, but it is important to avoid unnecessary folder depth as it can make the system time-consuming to browse. 

Simply put, the most common way of deciding your Folder structure is to consider what your users will find most useful to "browse" through in order to find assets they are looking for.

In the case of a University, often the two most important bits of information about an asset are the asset type (e.g. Photograph, Document) and the Faculty that the asset relates to. Either of these could make for a suitable start to your Folder structure, depending on which is a more important distinction for your users. In some cases it may be more suitable to browse into "Photography" and then narrow down to a specific faculty, in other scenarios it may be more useful to view all of the files relating to a faculty and then the type of file would be a secondary lens. It is possible to use both of these as part of your navigation by using Sub-Folders or Filters, as shown in the examples below:

Faculties as top-level Folders, filetypes as sub-folders

Filetypes as top-level folders, faculties as sub-folders

Neither of these solutions are inherently better, it just depends which solution is a better fit for your organisation. The downside of both of these is that the sub-folders will result in your assets being split across the system, meaning that it would be difficult to find 'all' Documents (in the case of the first example).

This potential issue demonstrates why your Attributes are equally important to your Folder structure, and the issues with considering them independently.

Customising your Attributes

Attributes control the different fields available for storing information (metadata) about your assets. Whilst it is possible to have fairly generic terms such as 'Description' and 'Keywords', it is often useful to be more specific (i.e. 'Country', 'Photographer') as it will prompt your users to enter certain information in a more consistent manner - especially if you set the attribute to be a defined dropdown list, for example. It is possible to make a Keywords attribute more effective by using a controlled vocabulary, possibly with a hierarchy and synonyms where appropriate. 

When first configuring an Asset Bank you will discover that there is a range of different Attributes that are already created in the system as a baseline. The majority of these can be deleted if they are not needed, or alternatively, they can be hidden from sight in the case of attributes such as 'ID' or 'Size'. It is possible to create new Attributes in order to ensure you are storing all of the relevant information about your assets in a way that is easy to maintain. In the case of the University example above, some possible new Attributes could be: Faculty / Filetype (assuming not Folders) License information (are there specific terms of use?) Photographer (who took the image?) Source (where is the asset from?) Information about your images that is more descriptive could then be captured in the Keywords attribute using a hierarchy, such as: Ethnicity Gender Location Name(s) Number of people  A blend of Folders/Sub-Folders, Attributes, plus an effective Keyword hierarchy will help to ensure your system is easy to use during both upload and download processes, plus your assets will be much easier to find through browsing or searching.

Asset Bank's default attributes

Controlling user access

Groups are used to give permission to your users and change which functionalities of the system are available to them. Folder permissions are the broadest way of controlling their access (e.g. can view all folders but can only download a specific one) but it is also possible to be more specific using other options such as Attribute Exclusions.

The functionality and assets that are available to a user is based on the Groups that they are placed by the system administrator. The different levels of access that a group will have is controlled on a folder-by-folder basis. It is also possible to state whether users will need approval to perform certain actions (e.g. downloading) or whether they can freely do so.

If you need to control permissions on an asset-by-asset basis then this can be achieved by either using file-based permissions, or by using Attribute Exclusions which enables you to hide assets depending on the metadata of the asset. For example, if the default attribute "Active Status" is set to "Expired", then the asset will not be visible to your users.

There is also the option to control the visibility of your attributes as well as which filters and download options are available to your users. These are important options that allow you to greater customise the experience of your users.

Additional guidance

The university example mentioned above is detailed more extensively in a standalone document which you can access through Google Sheets or as an Excel spreadsheet download. 

These areas are a great starting point to setting up an Asset Bank, but there are many more areas which can be customised in order to maximise the effectiveness of your system, such as customising the search options or changing branding for specific user groups.

It's important to ensure the system is built with your users in mind, as the only way to ensure a DAM implementation is successful is ensuring that it is an enjoyable and useful experience for your users. Regular consultation with your users during the configuration stage (and even when the system has gone live) is a great way to ensure the decisions you make are beneficial for all.

Our years of experience in configuring the software can also be a useful resource, so if you'd like any more advice or assistance with this, please get in touch so we can arrange a conversation.