Another DAM Blog

Blog about Digital Asset Management


1 Comment

How do I address user error?

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 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 any more. 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 in the system the issue was occurring 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, process 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 having any instructions at all (see assumptions for similar results).
  • Do not explain how nor why something works nor even IF it actually works. People are just supposed to know this simply by osmosis or being born with this information.
  • 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.
  • 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 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 share all 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 multiple when you do this.
  • Never take any vacation nor breaks. It will not catch up with you in any way.

I only wish these were all so ridiculous that these did not ever happen nor were even thought of. Sadly, they actually do. Too often.

How do you address user error?


1 Comment

What is the best DAM solution?


What specifically is your organization going to do with Digital Asset Management?

For those of you who have not read this blog before or did not realize it, I am and remain vendor agnostic. Everyone should realize there is no one DAM fits all solution. Many DAM vendors will claim their solution is the best for you and they may try to sell you a solution even if it does not meet your needs.

I have looked at 90 DAM solutions in the past. Someone claimed there are as many as 150. Which solution is right for your organization?

The right DAM solution for your organization will depend on the following:

  • Your business needs
  • Your organization’s particular use cases
  • The types of assets you are dealing with in the past, present and near future (Are they all supported?)
  • The file size of the assets (can that solution deliver your assets or is there a bandwidth issue using one model versus another?)
  • Usability of the DAM system
  • Your potential users, their geographic location(s) and their available bandwidth
  • What features you need, want and/or would like to have (not just because it is shiny or sounds cool, but is proven to work)
  • How many users, number of assets and fields of metadata can the solution scale to
  • Internal IT support (Got any?)
  • Your budget (Cost is not the only factor, unless you only want to pay for something that does not meet your needs)
  • Your schedule (make room)
  • Your organization’s adoption of change
  • And many other factors

Again, there is no one-size-fits-all DAM solution. There is not one DAM system that could monopolize the whole field of Digital Asset Management. Of course, there are bigger vendors than others, vendors that only do DAM, some open source solutions and some systems which will work together with other systems you may have.

Each DAM system and solution is different. Some upload differently. Some handle file names differently. Some have more strengths in some areas than others. Some have more weakness because they are less developed or updated less often. Some DAM systems are constantly updated, versioned, changed and/or bug fixed. While others are not so much.

What is the best DAM solution? There is no one answer. It depends. What are you going to do with it?

First, research within your organization what your organization has in place now and what it really needs going forward. Where are the gaps? This includes researching the people, processes and technologies you have now. In case your organization has no idea how to do this, look into using a consultant. Select a consultant that is not tied to any specific DAM vendor(s) unless you have already made a decision on using a particular system. Hopefully, it will meet your organization’s needs.

What are the goals of the organization (not just one person) for the DAM? Which systems meet those goals?

Which system meets the business needs as described early on?

Which DAM system is scalable? (scalable for your assets, metadata, users and workflow)

Which DAM vendor and system can your organization work with? Is it too complex with too many features? Is it too simplified with not enough features? Is the vendor available before and after the commitment to using their system/services? Or is all outsourced?

Which DAM system make no sense to your engineers nor  IT department?

Which DAM system can work with your organization’s use cases?

Which DAM vendor can tell you how it would work and then show you a working example from start to finish using your assets?

Which DAM vendor is friendly to you just for your business, but has no existing support for you after you sign up?

Which DAM vendor can not show you anything that works, but will promise you the moon and stars? Which DAM vendor should you run (do not walk) away from?

Which DAM vendor, integrator and system will deliver what you need? Which will/can not?

Which DAM vendors will offer you a white paper to download and have 5 different reps call you about the exact, same thing? (This would require them using a CRM system properly)

Which vendors will invite you to a webinar which you attend and you ask some questions by typing them in (which can be captured), but they ignore them and then call you a month later asking if you had any questions? Then, you ask what was the topic of the webinar, but the person calling you does not even know. (If you only knew how many webinars I attend per month)

Which DAM vendor is financially stable? Many DAM vendors are private companies while some are large publicly traded companies which have DAM as part of their available offerings.

Which DAM systems has had so many owners and different names and different development teams that barely anyone knows how to manage it or use it even on the vendor’s side?

Would you pick a DAM solution without consulting your IT department first? Not a good idea.

Would you pick a DAM solution based on a game of golf with rep or sitting in a sauna with them? What does either of these have to do with selecting technology that meets your organization’s needs? Analyst Theresa Regli warns us about this. Heed that warning.

Did you really think I was going to mention one vendor? One product? One service? Seriously? No.

Be wary of any vendor (or anyone for that matter) saying they have the right solution for you without them knowing anything about your organization, the people, the technology you use, your use cases and your specific reasons for seeking a DAM solution.