TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
In addition to what others have posted, I might add a curriculum and documentation development methodology I've always found garners superb results: work backwards.
Initially, forget about the product, features, and the UI. Focus on the end results that the customer produces using your tools. There are undoubtedly certain cases or types of applications (or whatever) that your customers develop more than others. What's hot right now? What are your customers demanding?
Once you know what your customers are building (or will build) with your tools, identify the major categories of output, divide up the curriculum, and then methodically show them how to build the things they want. The examples and demos built into the tutorials don't even have to be all that sophisticated. Just show them the basics so they get up and running fast.
I've used this "backward" approach at Borland and Microsoft in the past with some pretty sophisticated tools. It works. It also tends to focus the training, eliminating interesting but potentially irrelevant tangents. Just show your customers how to build what they want to build. Forget about everything else. They'll love you for it.
Once you have a core set of courses, you can then add more sophisticated training that works off you foundation, but still based on customer direction and feedback.
I find if you truly put the customer first and figure out what they're producing with your software tools, the training approach sorts itself out.
Troy Klukewich
Information Architect
Oracle
----- Original Message ----
From: V. Camgros <camgros -at- mindspring -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Monday, June 25, 2007 11:27:07 AM
Subject: designing software tutorials
Hello colleagues,
I seldom post on this list, though I read your discussion with interest and often respond to individuals when I think I might have a contribution. Now I am faced with an opportunity and would like your opinions on how to best respond to it.
I work for a small startup that makes Java developer tools. We've recently re-designed the product and now my management wants new product tutorials developed to match.
I know that the new tutorials must be modular, written to answer the needs of the specific target audiences, and easy to understand. Beyond that, the field is so completely wide open that it feels like my mind might explode.
And so my question to you: How would you go about planning this redesign? What books, web sites, blogs, whathaveyou are essential to informing your efforts when attempting to train your uses to be successful with your products.
My thanks in advance for any and all advice. I will attempt a summary post if it seems warranted.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
