You may have read my call for a DAM Glossary from February 2013. Recently, Ralph Windsor started http://damglossary.org using a previously existing DAM Glossary. This publicly available website has no sponsors, is freely available, is as vendor neutral as we can hope for and allows users to append to this DAM Glossary (after registering). But the DAM Glossary is not yet complete. There are plenty of words, terms and definitions still missing. In order for the DAM community to benefit from this DAM glossary, we need to append these to the DAM Glossary.
Append those missing words, terms and definitions
Now the DAM community needs your help to append this DAM glossary with all the missing DAM words and their respective definitions. Look at it and see which words/terms are missing. Earlier, I found a few terms missing off the top of my head, such as:
Rendition (not the CIA’s version)
SAAS
Transformation (not related to that movie with similar title)
You may find other missing words/terms and other respective definitions in a vendor neutral sense. All you need to do is register on http://damglossary.org/register and apply the missing acronyms, definitions and words
Why should we append the DAM Glossary?
Several vendors (you know who you are) use special words regularly in their marketing, instruction, consulting and user interface. When you ask for a glossary of terms with definitions, it rarely includes all those super special words they use. If you were to ask three people who work for the same vendor for the definition of a particular word, you may get more than three different definitions. Some vendors themselves have not yet defined these special words in writing internally, but use them externally. Not only is this unacceptable, but this confusion propagates fear, uncertainty and doubt (FUD) in the DAM community and market itself.
Enough. If we are going to listen to or use special DAM words/terms/acronyms to explain functionality and tools in the DAM space, these better be defined either in the common dictionary or in damglossary.org. If it isn’t, point it out and ask for a written definition to be shared. Then have it shared with everyone on damglossary.org. That way we will not have to guess nor ask constantly what does that [frustrated] word mean and why does everyone we ask have a [completely] different definition for it.
Start appending the DAM Glossary for the sake of clarity, consistency, transparency and knowledge sharing throughout the global DAM Community.
Many people do not read instructions. They may enjoy reading what they want to read, but instructions are not one of those preferred works of non-fiction that come to mind. When was the last time you read instructions? Why? There is often the assumption and expectation things will be easy to understand and easy to use. When we download a new software application to one of our devices, do you see piles of instructions, guides, or manuals? Not likely.
And are we expecting other people to read instructions as well? Newsflash: many do not read instructions even if their lives depend on it. Some manufacturers in certain sectors include instructions to supply warnings, notices and legal documentation attempting to limit their liability in the case their product or service is (was) used incorrectly and disaster occurs. An example of this was a product mailed to homes as a free sample. This sample came in a small packet and included an image of a lemon on it. People instantly assumed it was lemonade mix, so they mixed it with water and drank it without ever reading what it said on the packet. The organization received countless calls and complaints from potential consumers who got sick. Most of them did not read the fact that this was dishwasher soap with a new lemon scent and an added citric acid cleaning agent. Reading is either clearly overrated for the masses or a means of separating the people who want to be informed from those who are too lazy/busy to bother.
Some manufacturers do not even include instructions anymore. Why? The product or service should be easy enough and users should just want to use it. They expect user adoption magically happen with some high hopes. Maybe that works with some mobile devices and some of their respective apps through simple, smart design. Never mind the precautions, warnings or issues that could arise. What could possibly go wrong? Users are smart enough to just know how to use it, right? Well, if you add some humans to any equation, you will get some inconsistencies, variables, and yes… errors. Sure, we can blame the:
poorly designed user interface (usability testing can help identify these issues)
lack of forethought in the system implementation, so everyone must think like the person who created it (user testing can help identify these issues as long as they walk through all the processes and note what/where is a miss)
the whoops on the real world which avoids the end-to-end walk-through of a solution to be sure it works
One organization had a lot of user errors, so they started focusing on the tasks that caused the user errors and tracked them. This could identify system flaws needing correction. Here is how to start on the path of accountability. Every instance an error happened:
the user was tracked by name (who)
the type of error was tracked (what)
the frequency of the error was tracked (when)
where the issue was occurring in the system was tracked (where)
what the user did incorrectly to cause the error was tracked (why)
the recommended changes to the process were communicated and documented (how)
Every time an error happened, a template email was sent to that individual user and their supervisor which included:
their specific error
the impact of this error to other users and the system (there often was one)
a recommended fix (for the user to complete)
a set time frame to fix the error properly (one to two business days)
a follow-up to be sure it was completed and the error log to close out that particular instance of that error.
Before implementing this error correction, the policy was fully documented and shared openly. As soon as this process started, error rates dropped significantly. That is the effect of accountability. Prior to this, accountability was not visible. Note that errors do not completely disappear because “perfection” is not a realistic goal for any organization. There is room for improvement for users, processes, and likely the system.
How to have MORE errors
There are the counterpoints to all this…
Assume too much or just assume everything will work the way you expect it to (just like the world will continue to revolve around you)
Ignore all issues you encounter. Do not verbally mention nor document in writing the issues for anyone to know about.
Do not test thoroughly or just ignore all testing completely (The testing fairy is coming soon. Just don’t wake up from that dream)
Do not verify any information down the exact character. In fact, just do not check on anything at all
Do not follow specific instructions. Do not have clear, up to date instructions. In fact, do not have any instructions at all (see assumptions for similar results).
Do not have a simple, easy to use GUI. If you really try, you could skip having a GUI completely.
Ignore all usability experts and their literature. Why would you want anyone to actually use the system your company paid for?
Believe everyone works and thinks like you (revisit assumptions again)
Be sure to have extra slow processors to make people believe the system is frozen or non-functional. It might be acceptable in some people’s mind if a simple process with a few bits of data take a half-hour to two hours to yield the results requested.
Be sure to blame the end-user when the system is not working, but it is best if the results are inconsistent just for that added bonus.
Confusion is always welcome. With open arms.
Do not document anything. When working with other companies, trust everyone freely and believe that they will document everything for you, understand it all your way, and do not share this documentation openly.
Believe everything (including coding) is really easy and it will automagically be completed overnight flawlessly. Every day. With no documentation nor specifications. Nor testing.
Every IT department can read minds. They have an app for that.
Eventually, everyone can read your mind.
Trust everyone. What could possibly go wrong? You do not need any verification either.
Do not plan ahead.
Do not train users. Ok, maybe once and believe they will remember it all.
Do not supply any ongoing support for your user community. They will figure it out.
Errors go away if you ignore them enough. Errors do not multiply when you do this. Errors are so much fun. Dream of getting more over time and it will happen in reality.
This blog covers many typical issues and questions asked about DAM solutions. One of the big questions is how to increase DAM user adoption (how many people really use the DAM).
Some people believe the DAM will magically be adopted by everyone who is involved and expect everyone to love the changes instantly, especially if it makes sense to management to have a DAM. If it were only that simple. A DAM is rarely a set it and forget it solution. A DAM can grow with the organization, but the assets don’t automagically get uploaded and used. That takes user involvement. Change in many places is often met with the excuse “we’ve always done it this old way and it works. So why change now?”
Here are a few things to consider regarding user adoption:
It is a change in mindset to begin using a DAM as a centralized repository for assets which can be searched thoroughly instead of using any prior asset storage methods. Why do I need a DAM? This involves explaining to users exactly how and why the DAM will make their lives and work easier.
It is a change in workflow to use a DAM. In order to change the workflow to use a DAM, the users pre-DAM workflows first need to be understood and documented for each role by interviewing people who will potentially use the DAM in the future. Genuinely ask users for their assistance and feedback on a regular basis. Ask them to be open, but respectful with their comments/suggestions, use candor and discuss the workflow thoroughly from beginning to end. Ask senior employees as well as junior employees because their perspectives may vary as well as their ideas for improvement. Listen to the critics you interview with a grain of salt and see what valid points they make. You may find that mind sets may be stronger with some people than others.Early user involvement will help user adoption. This is particularly true if the DAM and its workflows directly help the users in their daily operations and resolves some of their previous workflow issues. If users see the DAM and the new workflows using the DAM as beneficial and easier in the long run than what they used to do in their previous workflows, user adoption will occur.
What are their current issues with the workflow without a DAM?
How do they search and find assets without a DAM?
How long does it take them?
Can they find what they are looking for most of the time?
Does everyone understand their role in the workflow?
Do they have any ideas on what could be done to improve the workflow?
What are the workflow variables? How can they be minimized or handled better?
What is missing?
How will the DAM be rolled out to users? Will it be rolled out by:
Date
Project
Department/Group
User/organizational role
Make sure to have a lot of patience. User adoption, acceptance and understanding will not happen overnight.
Users will need some training depending on their role and involvement with the DAM. No one will come out of the womb with this knowledge, but try to keep it simple. If you need a software engineering degree to use the DAM, you might need to have some engineers make it easier to use. Hopefully, the DAM has an easy-to-use GUI (Graphical user interface).
Threats of firing employees who do not “accept” generally do not go over very well and are rarely fruitful. Some employees may have great difficulty changing their workflow and if they clearly “don’t get it” after numerous training attempts and some time to adjust to the changes, they may need to be reassigned to something else or possibly dismissed if they can not perform the new workflow tasks.
Have some type of support for the DAM users and the workflow in person as well as documented in writing. This can include a service level agreement from the DAM vendor, but an administrator who knows the organization and workflows around how the DAM is used is recommended. Having step-by-step instructions with screen shots can help the documentation. Any documentation should be kept up-to-date whenever the organization and workflow evolves.
What is the best use the skills and institutional knowledge of the users and roles in the new workflow with a DAM? What will need to change and what will remain the same for each user/organizational role?
How will metadata be acquired or created for assets to be uploaded/imported to the DAM?
If you are missing some people with a particular set of skills for this new workflow, some people may need additional training or hire some with these new talents. This may include skills to deal with metadata, taxonomy and various scripting to automate parts of the workflow when possible.
Having a contest to help name the DAM may help give users an increased sense of ownership. Eventually, many of the assets the users create, acquire or use on a daily basis may be uploaded to the DAM. The more the organization recognizes the DAM as a resource where users know they can find what they need, the quicker the user adoption will often occur.
As more assets get uploaded to the DAM, promote the existence of assets available in the DAM to users and potential users to increase awareness. This will build the DAM as known resource which will increase in popularity and increase user adoption.
Another DAM Blog 