Bonnie Ladwig
Bonnie has been fortunate to conceive a vision for what her DAM system could be, and seen it come to fruition. The experience has delivered priceless insights – that she happily shares.
What companies/organizations have you worked for as a DAM professional? What was your role at each?
I have been Cybrarian for The Integer Group in Denver since June 2003. I started as Archivist and Asset Manager for the agency. Those first couple of years, I did what I would call “manual DAM,” in which files were posted in a folder-organized system on read-only shares in our network while and also archived to DVD. Nothing was available online, in a database, or searchable except by file name, so a lot of time and effort was put into naming conventions. The only way to access the files was to navigate the folder structure.
Archiving and the idea of better organizing assets for users at the agency led me to get my master’s in Library and Information Science from University of Denver. Early on in my education (2004–2009), the idea of handling born digital assets was more an anomaly than the common practice it is today. While my education provided me a strong foundation in library science—that aligned with archives and records management as well as standard metadata schemas—it lacked in true DAM. But I found that many library science aspects came across.
My official foray into DAM began with a DAM system and the dream of having the archives accessible—with visuals of the final work—via a website for creatives within the agency began to take root. During the next few years, the agency significantly grew which translated to more and more assets that needed to be accessible. I realized that metadata would be key in helping users locate assets because the talent of remembering job numbers from year to year was dying off. This led me to develop a custom metadata schema that fit with information the agency was already capturing. During that same time, we outgrew what we felt our initial DAM system could handle before it could be launched to the agency. Even though the website was not launched, I kept gathering the necessary metadata and could at least search on my machine. I did maintain the read-only file shares as well.
About six years ago we purchased a different DAM system. The goals were to enable users to work off the server as well as archive to tape vs. DVD and have the archives searchable visually via a website available to our studio artists, which is still in use today. This was a huge shift in DAM for us. Of course it proved that the base DAM system didn’t fit all of our needs. While it did have a database to which metadata could be added, the addition of metadata was manual and cumbersome. Three years later, we ended up purchasing a keyword search tool that would allow metadata to be searched. Users across the agency could search for final art reference to determine which files they needed in high resolution be it for a client request or comping purposes. Because of the sheer number of assets we had within the system, both live and on tape, the search proved too sluggish to benefit users.
In late in 2011 the game changed again when we started work on our own homegrown solution with a dedicated developer and a UX designer. This web application would allow users to filter and/or search across smaller set of assets (final reference files) vs. the entire asset library of millions of assets. The metadata schema I had developed back in 2004 was still of value and could finally be used as it was intended! The assets in the web application were downloadable, allowing users to use the assets in presentations or to mark them up for repurposing. The web application also allowed users to request high-resolution assets via a quick asset request system that sent an email to a select group of users to fulfill. While the homegrown solution took roughly a year to build and there were more hurdles than I was expecting it was launched to the agency in the first quarter of 2013. We hit a few stumbling blocks during launch but had a solid system working by spring. It was the first time that the agency had access to past work and the fact that users could filter and search to find what was needed was met with excitement. Nearly half the agency had logged into the system within six months. I was the product owner as well as the agency trainer throughout the entire development process. It was a huge learning curve to get something done from scratch, but it was rewarding.
In January 2015 we realized that improvements to the 1.0 web application needed to be addressed. I once again was product owner and the agency trainer for phase 2.0 development. While 1.0 had functioned decently when it was launched, it was no longer seen as fast enough for our users needs. We also saw the opportunity to change the way it worked to allow the application to be faster for the user as well as more scalable to more libraries. This decision ended up changing the user experience as well. We launched 2.0 in mid September with a whole different look and feel, expanded the libraries available, and made it wicked fast. Now, two months after the 2.0 launch, we are receiving solid feedback on how much better this version is, which is fantastic.
For me, DAM was a long and arduous journey that required constant advocating as well as steep learning curves and many sales pitches. But, in general, what we have out now to our users is in many ways what I had hoped would be possible way back when DAM was in its infancy. It is possible to not completely drown in assets and still get a DAM out.
How do you describe digital asset management to others?
The goal of a DAM is to be a one-stop shop for the user to locate needed assets—either current or historical—be it by subject, branch of a business, brand, or client among other. DAM can occur within a department or multiple departments, across an entire business, across various offices, shared to various other business partners, or even open to the public at-large. DAM should help users quickly find what they are looking for. Specifically, in my case, DAM is a web application containing the finished advertising reference visuals created that allows users to quickly find what they are looking for from a previous campaign. The application can also be used by someone new to the client or the agency as a site that allows the user to review the historic work that has been done for a client.
Our DAM enables users to filter criteria and/or search a text field to narrow their searches to a smaller subset. Our DAM libraries are culled to only show the final advertising visuals vs. all the pieces and parts (placed files, stages of retouching, etc.) that make up the visual, which is stored in another archive. Currently our DAM is nearing 200,000 assets whereas our archive contains well over 2 million assets.
What’s the most important thing for someone new to DAM to understand about DAM?
It’s a huge undertaking to get it done right. Nothing works straight out of the box regardless of what the salesperson says. If you are not overwhelmed by the sheer number of assets you have to wrangle, then you are doing it wrong.
Once you realize just how many assets there are, assess them and determine which ones would offer the most bang for the buck to your users. If you can temporarily reduce the scope to only tackle one or two types of asset collections, then you will have a better chance of success and of getting needed feedback to help determine the course of the next sections of collections that need to be included. Finally, listen to your users! They provide of information of what would best work for them just by talking about the business itself. The best ideas can come from a casual, water-cooler conversation.
If you weren’t doing DAM as a career, what would you be doing?
I would probably be working in a museum archive somewhere, wishing they had the ability to have a DAM. A DAM would be a glorious way to view the collection contents without having to always go into the physical archives.
What is your ongoing greatest challenge with DAM?
We just did a 2.0 launch in September of this year. It proved to be a lengthy redesign of both the user experience as well as how the data is ingested. As usual, the development took longer than I would have liked. Now that we have the shiny new version of our DAM out there, the biggest challenge is maintaining iterative development. Prior to this launch, we were stagnant for nearly two years on development. Because our DAM is only internal at the moment any time client development projects come in, development on the application stagnates. I am sure many people in DAM experience this frustration.
An ongoing challenge that I know all of us face is how to stay on top of the work that needs to be available in the system. I am constantly reevaluating how I can improve my workflow as well as other options for automation and metadata input that would improve the user experience.
What is your vision for DAM? What will it look like in 5 years?
I believe that the need for DAM will continue to grow in the coming years. I have reviewed several DAM systems in the last year in which vast improvements have been made to allow administrators to get web applications out to users faster than was possible in the recent past. I still do not feel any of the DAM systems truly work 100% out of the box, but with the varying complexity of DAM needs, I do not know how that would ever be possible. The more work one does up front, such as organizing/analyzing assets, having a solid understand of processes, and determining where DAM needs to fit prior to purchasing a DAM solution, the better off one will be.
While some have said that the time for DAM is over, I feel there is still significant growth that will happen in DAM in the coming years. I foresee that the time between purchase and implementation of DAM will become much faster due to additional development of DAM. I also believe there will be additional facets to DAM that may not even be on the radar now. It is going to be exciting to both observe and be a part of what happens.
What was your biggest mistake with regard to DAM?
I prefer the term hurdle vs. mistake. The biggest hurdle for me during 2.0 development was translating the user requirements into concise developer tasks. Oftentimes I felt I had clearly defined a requirement only to have the developer come back with questions that I didn’t even think would relate to what I was looking to have executed.
While I feel I am making improvements in writing user requirements, I know I still have a lot more to learn, which I will do with each project I work on. Another challenge that I consider a work in progress is ensuring that I provide a use case that allows both scalability as well as capping the scope to prevent developing against all possibilities in the entire universe—it’s a very delicate balance.
What was your biggest success with regard to DAM?
Our biggest success is that the web application has reached over 50% of our users in under two months after its launch. Because of its speed and ease of use, users are showing those previously unaware of the site how to use the application as well as how it is a solid resource at their fingertips, which to me is the best indication of success.
For me, personally, my biggest success is seeing what I dreamed as DAM all those years ago actually being in the hands of our users. It was a long journey but not only did I make it through, I am proud of what was produced. Now on to phase 3.0.
This interview originally appeared on DAM Guru on Mon, 30 Nov 2015. For more DAM News interviews, see the interviews index page.
Share this Article: