A blog reader asked about how to create use cases for DAM.  I gave a presentation about this topic during a DAM conference.

What use cases did you have before DAM was part of the equation? Before you had a DAM, were your workflows documented?

All too often, use cases are not documented. In fact, they may be locked in multiple silos where each person (even within the same group ) do things differently.  Therefore, migrating to a workflow with DAM becomes a mystery. Without use cases, the user adoption of the DAM is often lower if users do not know why nor how nor when to use the DAM.   Where does DAM fit in the users’ daily workflow? Use cases can also affect the choice of a DAM solution.

Use cases need to be documented and shared.

Another reason for having use cases is training for new people. How do newly hired people find out how to do their job? Are they born with this knowledge? Should an employer expect everyone to know how to use all the tools and policies of the organization to get their job done?  Not likely.

Enter a new person (new hire) to the organization. What are they supposed to do? What tools are involved? When do they use the DAM and for what purposes?  Should new people operate differently than people doing the same tasks for years within the same organization? Not likely, but they often do. Does each person who coaches a new person give their own version of how to do things (plus or minus a few steps)? Is this standardized? This is often not only due to a particular level of experience, but lack of documentation and poor training. And we expect consistency. Somehow. Maybe by mind reading? That is not likely going to happen.

When you start researching a DAM for your organization, instead of looking at shiny features, see if it would work well with your use cases by presenting them to the vendor during a demo. Have real assets you would likely be working with along with real use cases. Ask the vendor to demo their solution for your use cases with your assets with metadata from start to finish in front of you.

Start building use cases with what you have and how you do things today.

• What do you do today?
• How do you do it?
• Who does what?
• When does it happen?
• Why is it done that way?
• What is the process?
• What tools are used?
• How could this improve?
• How can this be done more consistently?

Be sure to consider the people, process and technology (in that order) which are involved from start to finish. Not sure who/how/what is involved? Ask by using…

• Surveys
  • Online or paper form, with long answer questions, not simply ratings
  • All roles (don’t expect 100% return, even with a prize)
  • Send to everyone including decision makers and potential DAM users doing the daily work
• Group workshops
  • Be aware of who is talking and who is not
  • Include all group members
  • In case extroverts have all the say while introverts remain quiet in the corner getting frustrated, have people take turns talking so everyone contributes
• Individual interviews of:
  • Not just senior staff, but junior staff for a varying perspective
  • Both computer literate and those who prefer analog
  • All roles

When reviewing who is working, consider their role in the organization, not just their name so you can build and scale these job functions as needed.

Who makes the initial request? Who/What takes the request? Who handles/processes the request? Where does the request go after that? and after that? and after that? (note a pattern to fill the gaps)

How many other people do the same task(s)? Is this redundancy to handle volume or act as a backup? Can this scale up or down today based on the amount of work to do?

What is the volume of requests? Where do the requests get filled/completed? Who does this? Who/What delivers the end product/service?

Consider the whole life cycle of typical project from idea to delivery. And walk through all the steps.

How much communication is involved in all this? Likely not enough.  It is not enough to lock decision makers in a room. As discussed earlier, there are different points of view to keep in mind.

Keep the communication channels open among all differing points of view.

Stay positive. When negative points need focusing, laugh about it, then find a resolution.

Create roles. Envision the end result. Have a goal. Make it clear. Try even mind mapping. Simplify when in doubt. Follow through. Measure the results.

Avoid jargon and acronyms (so anyone can understand it). Be open to feedback, but have a schedule with deadlines and accountability.

However you create use cases, write them down and share it within your organization.

Let us know when you are ready for vendor neutral consulting on Digital Asset Management. We can also help you create your use cases.

How do you create use cases for DAM?