Question

I’m working in a small company and weeks away from deploying a web-app that will be used a lot. Everyone at one location will have to learn to use it, and although I think it’s pretty easy and intuitive I may be biased.
I’ve written a help guide with plenty of screenshots that’s available on every page, but I’ll still need to train everyone. What’s the best way? How do you take a step back and explain code you’ve been working on for weeks?

Answer 1

First try to avoid the training:

Perform usability testing to ensure your web app is intuitive. Usability testing is a very important aspect of testing and it is often ignored. How you see your system will probably be very different as how a new user sees your system.

Also add contextual help as often as you can. For example when I hover over a tag in stack overflow, I know exactly what clicking it will do, because it tells me.

Also this may seem obvious, but make sure you link to your documentation from the site itself. People may not think of looking in your documentation unless its right in front of their eyes.

About training documentation:

Try to split up your material into how your users would use the system. I personally like the ‘trails’ option that Sun created for their Java tutorials. In this tutorial you can do several things, and you can chose on which trail you’d like to go.

Support random reads in your help documentation. If they have a task to do in your web app, then they should be able to get help on that without reading a bunch of unrelated content.

Make sure your documentation is searchable.

About actual training sessions:

If you are actually performing training sessions, stay away from explaining anything related to your code at all. You don’t need to know about the engine to drive a car.

Try to split up your training sessions into very focused aspects of your system. If you only have 1 training session available to you then just do one specialized use case of your system + the overall description of the system. Refer to the different parts of documentation where they can get help.

Letting the community help itself:

No matter how extensive your documentation is, you’ll always have cases that you didn’t cover. That’s why it’s a good idea to have a forum available to all users of the system. Allow them to ask each other questions.

You can review this forum and add content to your documentation as needed.

You could also open up a wiki for the documentation itself, but this is probably not desirable if your user base isn’t very large.