Another DAM Blog

Blog about Digital Asset Management

Tag Archives: users


by 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 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 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 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.
  • 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?


by 1 Comment

Who owns the DAM in your organization?


Everyone who uses the DAM should take pride in sharing their work in their DAM with other users. The organization owns the DAM and they are responsible for it. When it comes to having a go-to person, it comes down to the:

  • Stakeholder (or sponsor)
  • Lead who runs the system based on the needs of organization

Of course, there is a stakeholder in your organization who:

  • Champions the idea and clear vision of having a DAM in use
  • Funds the project of acquiring and implementing a DAM within the organization
  • Requests the DAM to meet specific high level business needs and use cases for at least one group/department in the beginning
  • Approves the scaling and fosters sharing the DAM and its assets across departments in the organization
  • Instruments the change management needed from the top down
  • Requisites a small team to be assembled and work on DAM
  • Stops the bickering between groups. Everyone works within the same organization with similar goals set by stakeholders when it comes to digital assets and can share what they have
  • Receives high level, weekly reports on the progress of the DAM, relative to the organization.
  • Budgets for the DAM continually to meet the business needs of each fiscal period
  • Owns the DAM as an ongoing business solution

It is up to your organization to decide who that person happens to be and where the accountability lies. It could be a C-level executive, a Vice President, a Managing Director or whomever has the authority/approval to do this for the benefit of the organization and its clients. They should understand the value of a DAM and, in turn, be shown this value (in a report or dashboard) as the DAM is used within the organization.

At least one person manages the DAM and often reports directly to the stakeholder. They would oversee the daily operations, train and support users. They are not simply a database administrator, but someone who understands the use cases for the DAM solution, how users should use the DAM and help meet the organization’s business needs involving digital assets.

Who owns the DAM in your organization?


by 3 Comments

What are the levels of DAM experience?

Before I mention DAM jobs descriptions themselves, many of these positions require experience, but what are the levels of experience in Digital Asset Management? How do you qualify the experience or even rank experience with DAM?

There are several levels of DAM experience from basic (1) to increasing in complexity (7). These levels include:

  1. Simple DAM user (this is often the majority of DAM users)
  2. Power user(aka Super users)
  3. Practitioner in DAM Operations
  4. DAM Administrator
    • Possibly network maintenance
    • Possibly maintaining servers
    • Maintaining database(s)
    • Working with API and Web Services
    • Running reports from DAM
  5. Configuration
    • Understanding the relationship of DAM system options, implications of the decisions made and configuring those system options to best suit business/workflow needs
    • Testing configurations to make sure they work the way they are intended to
    • Setting up roles
    • Setting permissions per role
    • Setting users within those roles
  6. Implementation
  7. Customization
    • Identify and understand what is missing from the system which your organization may need
    • Explaining what is missing from the system with written documentation
    • Explaining the value of adding the customization since it will cost extra (time and/or money)
    • Drafting the vision of what the customization may look like and how it could work with a written end result.
    • Possibly coding the solution
    • Thorough testing of solution

Ultimately, the best would be to have experience in all of  these hands-on experience at one point or another. If this is not an option, try to experience the most number of levels available. This way, you have experienced what it is like to do this work, know what is involved and ultimately train others in the future on how to do this work more efficiently and effectively. As a Digital Asset Manager, I have experienced all listed above at some point or another over the years. This helps me when I need to write documentation for a specific role (audience) or when I give training so I know what is involved in what that user needs to do with the DAM. I try to not over complicate any explanation to any particular person unless they really need more detail, so I try to keep information at a high enough level to minimize confusion.

Now, if you want to discern between individuals who have similar experience in these roles, then start by asking:

  • How many different DAM solutions have they worked with?
  • How many different organizations using DAM solutions have they worked on?
  • How long did they use the DAM and how often?
  • How many DAM solutions were successfully implemented and are still in use today?
  • How many users does the DAM solution serve?
  • How many assets are managed?
  • How do they measure ROI using DAM?

You could use these questions in a DAM job interview as well. What levels of experience do you have with DAM?

There is plenty to learn.