Today I was asked by a colleague to explain how to book a meeting room in Outlook. I was a bit surprised with the question but was able to help. It is one of those computer tasks you tend to expect that people would know this.
It reminded me of a case long ago where one of my team members said we needed to train users on the defect tracking tool Adminitrack that we used. My response was that it would not be necessary since the tool is so simple that if they wouldn't be able to figure it out themselves, they wouldn't be suitable for testing the much more complex business system that was to be tested.
It makes you wonder again how much user documentation is required.
When running a project for a new system, the user community might feel uncertain and demand comprehensive user manuals to be written even though you know that they will hardly be used.
If you buy a piece of technology these days, how big is the manual they ship with it?
We bought the other day a new mobile phone for my daughter and I instructed her to read the user guide. She looked at me as if I asked her the strangest thing. The guide was smaller than the phone and was no bigger than a few pages. She was finished quickly and would continue to rely on dad if she wouldn't know something.
But that is the way it goes. I do the same. First ask somebody nearby and only the look for written assistance in second instance.
So we should keep documentation concise, provided that we build our technology to be intuitive and in alignment with the processes and tasks at hand. Train the users and let them rely on asking the more experienced ones first. Also provide assistance through the IT super users, relation managers or whatever name you have for them. This way you grow a knowledge ecosystem that is much more effective and efficient than the large and expensive volumes of documentation.
