16 06 2010
Documentation – User Exploration
As I’m now leaving my current job to new ventures, I’m having to perform hand over of use of certain systems to other users. As I’ve now used these systems for over 18 months, I’m fully comfortable with their short-comings and the kinks which make the system poor. There are many facets to one particular system (specifically, a customer database system) that it becomes difficult to write up step by step procedures for using the system. Every day there will be one of a number of unexpected events which require a judgement call, which I now perform on impulse, without having to think too in-depth about why I make a certain choice. I just know inside and out, what the system does with the data I store and what I and other users may need when digging the data out again.
One way I could document the use of this system is a flow chart. I can already imagine the complexity of this flowchart due to the number of choices that are made every day. A step-by-step procedure guide would be so full of annotated comments that it would eventually become almost unbearable to follow properly.
I’m figuring the best way to perform this handover is to show the user taking over how the system works, rather than how to use it. Instead of showing step by step in detail how to perform a certain task, I will show them how the system stores the data and what is done in the background, along with reasons why. Then, the user can build their own ways of using the system and build their own “best practices”.
The easiest way to do this then, is with minimal written documentation; no screeds upon screeds of written documents detailing every facet and field, but rather a short outline document purely for reference, with most of the training being perform desk-side. I will be hopefully doing it over multiple sessions (instead of one cram session and then hoping he remembers it all). I’ll have to take time to show in detail each form, and what each field is used for (both in storage and in retrieval, such as searching and report generation). This way I can introduce and explain the short-comings that the system has, and being to train their mind into making quick decisions during a batch of work.
I’m calling this method “User Exploration” (whether or not it’s the right phrase is another question for another day), as opposed to Step By Step user documentation (see my previous post on this), as what I’m doing is not showing the user how to perform a task, I’m showing them how to use a system which will be used to perform a task. The hope is, that once my replacement has built up a level of knowledge of the system, they can work as efficiently with it as I can, rather than spending a lot of time figuring how to do something when something doesn’t quite go to plan.