I've found that a good method is to tell your users that you would dearly love to hear any questions they may have and then answer those questions in your documentation (as well as directly). If someone says "How does it all fit together", add a diagram. If they say "I don't understand what this object/method/button does" add a paragraph on why the thing is there (incidentally, this is also a great time to ask yourself the same question and remove/modify the thing if you find you don't know the answer). If some question keeps coming up despite the fact that you think you've already answered it in the docs, move the explanation into a more prominent place or clarify it.
The problem with this approach is that you really have to work hard at soliciting user comments. Most people don't like asking questions which can make them appear stupid. So something that appears blatantly obvious to you may not be so obvious to other people but you may never find out because they are too embarrassed to ask. Another obstacle is inertia and unwillingness to explore. So really make it extra clear that you love questions and want to hear them from your users pretty-please with sugar on top.
Another important thing is to separate your documentation according to target audience, a board user will need different docs from an administrator from a developer from a board owner. Having to wade through stuff that doesn't concern them will turn people off the docs.
In reply to Re: creating documentation
by tirwhan
in thread creating documentation
by stonecolddevin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |