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?


2 Comments

What does a Digital Asset Manager need to know?

After reading one of my most popular blog posts, a few readers have asked “What does a Digital Asset Manager need to know?”
This is assuming an organization realizes why a Digital Asset Manager is needed who is skilled and experienced in the field.
That said, they will need to know how to work with the following:

People

  • Be helpful. You should there to help the people, the process, the technology and the information work together. No small feat in many cases nor a temporary effort.
  • Be resourceful.
  • Be honest. Brutally honest if needed. Do not hold back much. The truth may require revealing news people do not want to hear, but rather need to hear (if you have read my blog or know me well enough, you will know what I mean).
  • Be patient. Not everyone will be technical nor understand what is involved.
  • Listen. To your users. All of them. Not just to yourself talking and repeating yourself.
  • Be specific. Do not assume people know, even the obvious. Remember, not everyone is technical.
  • Explain issues and their solutions to the people who need to know about it in their perspective. Keep in mind who your audience isUse visuals to explain as needed. Document how to resolve issues often, then share this documentation openly and often. Repeat.
  • Simplify. Do not overcomplicate unless you like confusion, fixing errors and having delays.
  • Be an agent of change. Change, not because it is shiny/new/cool, but needed for increased effectiveness and efficiency across the organization.
  • Know who is responsible for what. If you are not in charge of something, who is? If no one is in charge, take charge. “Initiative isn’t given, you take it”…along with responsibility.
  • Speak up. Interject as needed. Do not ‘wait your turn’ or your points will be overlooked. Leave your emotions elsewhere. This is business.
  • Be accountable and hold others accountable for their actions (or lack thereof) when it comes to the DAM and everything else in your purview. It is a ‘two-way street’ whether we realize it or not. Top to bottom and back.
  • Be proactive as well as reactive as needed. You should not be ‘fire fighting’ issues all day, every day (otherwise, there is a prioritization and process issue).
  • How and when to say “No.” Contrary to some people’s belief, ‘yes men‘ can hurt the organization as well as themselves especially if a constant “yes” is believed to always be the right answer. It is not. Reality checks are necessary for all.
  • Do not kill yourself, physically nor mentally. Nor anyone else for that matter. Even if it starts to sound really tempting. Really.

Process

  • There is at least one process, right? And it is followed?
  • How do DAM users interact with the Digital Asset Management process and system?
  • Help establish a process, test the process in the real world, document the process in writing and train users on the process/workflow as needed (especially when lacking). Work one-on-one or with small groups. Why? Large groups and committees are like large ships…they are harder to steer in any direction and slower to start, stop or react in general. Don’t believe me? Try it. Find out yourself.
  • How does metadata entry occur from sources (owned internally and/or externally) to normalization of the data to entry into the DAM. Then, track the process all the way through to use within system to yield the requested search results.
  • Manage by assigning, measuring and prioritizing daily. Of what you ask?
    • Assets
    • Accuracy of metadata entries and usage
    • Error rates
    • Performance of systems and users
    • Tasks
    • Users
    • There is plenty more to assign, measure and prioritize…
  • Establish a process of user adoption from the beginning of the selection process of a DAM system to the integration of other systems to the regular operations of the solution. What are you doing to encourage your users?
  • How to make coffee (or tea) without spilling it nor burning yourself. (Like most things, carefully.)

Technology

  • Digital Asset Management solution within your organization
  • Metadata validation and when applicable, metadata automation
  • How to use and apply the LAMP solution stack (in case you thought there was nothing else to learn to improve your skills)

Information

  • Love information and data. Really. It may not love you back, but it is a give and take relationship. You get what you put into it, along with compounding value over time. Of course, I am talking about metadata. You should be one of the information experts within your organization.
  • Know what is available (and what is not), where it lives, how to get to it, how report on it, how to filter it and analyze it.Explain it. Train people on how to take ownership of it in their role, how to complete their part (metadata), the value of this information and why.
  • Know the difference between data, information and knowledge.
  • If you want a baseline to know how mature your DAM solution is now within your organization, start studying the DAM Maturity Model (DAM3), which was based on ECM3 as it continues to mature. Using DAM3, you can plot how mature your DAM solution is within organization today as well as where it could improve.

I write this as I leave my position where I was Digital Asset Manager for over 5 years. I have accepted another position as a Digital Asset Management professional in a different capacity to assist other organizations with DAM.

If you need vendor neutral assistance or advice on Digital Asset Management, let me know.


Leave a comment

Poll: How long did it take to get a DAM working within your organization?

As discussed earlier, how long did it take to get a DAM working within your organization from the day it was decided by stakeholders and sponsors to the day you measured user adoption with favorable results of a working Digital Asset Management solution will vary. Obviously, this is not just about a DAM vendor handing off an empty shell and running away, but rather having DAM with:

  • Defined users, roles and admins able to use the system
  • Up-to-date training with supporting documentation
  • Assets
  • Searchable Metadata
  • Working features and functionality
  • Configurations set for your initial needs (and adjustable for the future)
  • Any customization completed and in use by users

Answer this one question poll


Leave a comment

Why should I pay for the DAM when the entire organization uses it?


Someone asked me about this question and remembered I wrote about this briefly in an earlier blog post, but wanted me to ellaborate. So here is blog post to explain it.

Let us say one group or department is the original requester of a DAM solution within an organization. Likely this same department becomes the business owner, stakeholder and/or sponsor of the DAM solution. This same department or group pays to administer and maintain the DAM. They might pay for any monthly/quarterly/annual licensing fees and/or service level agreements (SLA) for the DAM solution as well. Now let us say other departments see the value in using the DAM to keep the organization’s branding, graphics, photographs, publications, presentations, reports, video or other intellectual property (IP). The DAM gets more user adoption by more departments. Now who pays for the DAM within this organization?

Often, what occurs is the original requester, sponsor or stakeholder continues paying for the DAM solution. Because of this, they might say “Wait, I am paying out of my department’s budget for other departments to benefit from this solution as well? What’s in for me? Why should I pay for the DAM when the entire organization uses it?”

Consider this idea “Why am I the only one paying for it? If we share the DAM, share the cost.”

Enter the idea of chargeback or simply charging the department who requests to acquire/create/use something with the actual expense in resources used by refunding it. This idea is likely a change for many companies in how they deal with budgets and how departments are accountable for the resources they use. This also keeps a department which may overtax another department’s resources in check. So, with this idea every department or group has their own budget as usual, but since every DAM user should have a unique login (right?) and possible different collections of assets they can access or share, why not split the total cost of these expenses based on actual usage of the DAM solution per department? Charge each department based on usage of the DAM solution.

If one department uses the DAM more than another department by a measurable amount or percentage, should they pay a larger share of the cost each month/quarter/year? Should each department be able to share this cost evenly or should each department pay for what they use based on a percentage? Or have one department pay for it all?

How do you measure usage of the DAM? With usage reports from the DAM which could list:

  • Who are the DAM users (by individual login) accessed the DAM? (keeping individual user accountability)
  • Who has the most active DAM users within a given period of time?
  • Who wants/needs/asks for the most time in administration, maintenance, support and/or training?
  • When did they access the DAM? (keeping time accountability)
  • How often did those users or group of users access the DAM? (time based usage)
  • How long did they access the DAM over a period of time? (number of minutes or hours)
  • How much was downloaded/exported from the DAM? (by the number of assets and/or file size if bandwidth is measured)
  • How much was uploaded/imported to the DAM? (by the number of assets and/or if bandwidth is measured)

I would recommend looking what you are paying for internally and externally to gauge what are the costs of doing business.

Some DAM vendors charge for bandwidth (how many GB is uploaded/downloaded to/from DAM within a given period). Some don’t.

Server space costs money regardless of whether it under your own IT department’s domain, a vendor’s domain or in the cloud. Who is using the storage space?

Is the data deduplicated? Do you want to dedupe the DAM data to minimize duplicate assets?

Some DAM vendors charge per DAM login or per concurrent user. Some DAM systems limit how many users you can have or the total users at one time. Can your organization add/remove DAM users without the vendor’s help?

How much does it cost to administer, support, maintain a DAM and train the DAM users? How much does it cost in errors and problems when you don’t?

Why should I pay for the DAM when the entire organization uses it?

Are these costs of doing business worth sharing as you share business tools such as a DAM solution?