Don’t we love reading DAM documentation? I am not referring to the pretty, glossy brochures you get from marketing that has to look great in order to sell you the product. I am referring to the actual DAM documentation which supposedly explains how the DAM works like the guides, manuals, feature sets, configuration options, compendiums of data and volumes of instructions. Instructions are always so easy to read, aren’t they?
Many DAM vendors are reluctant to show us their documentation until we have signed a contract with them. Then we are often stuck trying to understand these things. After we review the tables of contents and volumes of paperwork, we quickly begin to understand why we pay annual support fees for the DAM. We pay them to read and understand their own documentation.
Personally, I have read over the DAM documentation for a few DAM solutions I have used and had the same frustration, but I decided to do something about it. Here is a solution to have up to date, easy to use, easy to navigate documentation:
First, I asked for all the latest documentation (yes, I asked for more) the vendor had for their DAM product. It would help if the vendors updated their documentation as often as they updated the product itself.
Second, I wanted to know everything that was NOT covered in their documentation, such as the new features. If I had a question on how to do something with the DAM which was not discussed in the documentation, I asked. My questions were often forwarded directly to the engineers for an answer. This sometimes exposed more features and little known facts about the functionality of the product.
Then, with the permission of the vendor, I rewrote the documentation. Yes, it was all technical writing. I also had to translate some parts from ‘engineer speak’ back into English. One of the most useful things I did was I wrote step by step directions, complimented with screen shots to illustrate these steps.
- was not about to re-write the documentation into big thick paper manuals.
- was not about to print binders full of paper for each DAM user to refer to.
- was not about to chisel the documentation onto stone tablets.
- was not going to issue an eraser with each binder for changes.
- was not about to switch out endless pages per binder for changes.
- was not about to use a PDF because a user might accidentally refer to an older version of a PDF with different information which would not help them access immediate, up-to-date results.
This is the 21st century and we have better tools for documentation that occasionally changes, especially since we use computers anyhow. Welcome to the Web 2.o method of documentation. What I used was an enterprise wiki on our intranet. The enterprise wiki is open to anyone working within our organization’s network at any time from anywhere. The wiki is fully searchable and is kept up to date with latest information at all times. It is updated by me or anyone I assign to edit it. Any changes can be applied to the wiki in seconds. There is full version control, even down to a single character change. Every user can get an email update alerting them of any recent changes to the documentation.
How long did it take me to create the documentation on a wiki? It took me the same amount of time to write on this wiki than it would have as a PDF or paper, but it only takes seconds to update and disseminate to all users. Try that with paper or PDF.
Who uses wikis for their own business? Plenty of businesses are using wikis as a modern dissemination tool for documentation.
My question to all the vendors is when will they begin offering their documentation as a wiki for their clients as well as their own sanity?