In a world awash with software for various needs, one need is critical to get things going: knowledge. Bill Gates once said during the run-up to Microsoft’s 25th anniversary as a company, “Great software, anytime, anywhere.” Now that they are, people need to work them, and work them right. Training is good, but there comes a time when the trainer has to train other people. Then there are also different customization and configuration requirements.
In all my years working in the academe and the technology sector, becoming a technical writer—a user manual writer, in particular—was something I didn’t see coming my way. I wanted it 12 years ago, but, it happened anyway. I was told that my being a teacher made me cut for the job. And indeed I was.
 |
| I have since accumulated a collection of different instruction manual templates based on Microsoft Word and PowerPoint handout formats. I'm even working on one that will closely resemble a LEGO manual should the need arise for me to be like President Business. |
A day in the life
So I write instruction manuals all day, everyday (except when I’m conducting user training, which is my other role). But manual-making is not simply about narrating stories about getting things done. There’s a lot more to it that not many of our college computing graduates would actually consider it as a first-choice career.
From my personal experience, a typical software application instruction manual begins its lifecycle from a guided walk-through of the said software. At this stage, I will be introduced to the fundamental user interface and navigation techniques before proceeding to actually doing the business end of things using some mock data. After the walk-through, I would proceed to drafting the structure of the contents (which is likely to become the Table of Contents).
I already have prepared templates for certain project types which range from government agencies with mostly middle-aged users, to private firms with relatively younger users. I have formats for both Microsoft Word and Microsoft PowerPoint (Notes View) with partially prepared designs. Color schemes will be customized in ways appropriate for the requesting firm. The PowerPoint format has an added advantage: it is both a slideshow and a handout.
 |
| In PowerPoint format, my training slides are also the handouts. |
Next is content gathering. I will have gathered enough text instructions during the walk-through. Everything my guide dictates and does on the screen, I immediately type on a simple text editor like Notepad. Those instructions are just plain text, no formatting. I then capture screens for editing and conversion to lossless formats like Bitmap since compressed formats like JPEG have a tendency to blow up when embedded on a document or slideshow (they also lose quality with each save).
Now the writing begins. Manuals are not textbooks explaining theory and applications, much less novels that have conflict, climax and denovement (pronounced “de-noo-muh”, or resolution). You don’t just copy and paste your dictated text; you observe proper working sequence and correspondence with screens. Screens have to be properly sized to enable readability. Captions in Microsoft Word allow the creation of a table of figures.
 |
| I normally place a table of figures at the end of my user manuals for those who wish to navigate the contents based on their photographic memory. |
Sometimes, one must know the application enough that he/she can explain why certain buttons are clicked in a particular order. A good manual then must also explain the “why” before demonstrating the “how”, and in as compact a form as possible. Most user instructions are compacted in as few pages as possible, since many users don't even bother or have time to read a bible (not "The Bible"). A more compact manual is also more easily downloadable.
The end stages of the manual-writing lifecycle include revision and, at times, modification. A good manual must be sustainable, with modular parts that can be inserted, removed, swapped with other parts or have them slightly modified according to user software application permissions and roles. I’ve had requests that ask for as many as eight different editions.
A user manual is also software as it is a codification of rules and tips for an application's proper use. In the long run, they should be modular and scalable enough to facilitate upgrading and audit of changes.
A user manual is also software as it is a codification of rules and tips for an application's proper use. In the long run, they should be modular and scalable enough to facilitate upgrading and audit of changes.
Your need to know
You need to have a very good grasp of English writing, as well as English speaking if you happen to be like me who has to teach what he writes. English is here to stay as the global language of business and technology, but bear in mind that it comes in either of two acceptable forms of native-speaking: American and British. Be mindful of acceptable technical speaking too, so do your fair share of reading documentation of both American and British origins. Better if you read them aloud.
While not all have thorough teaching backgrounds like I do, it is not at all impossible for anyone to be a writer of instructions. Just follow Sharon Ferrett's adaptation of [Carl] Jung's and [David] Kolb's Adult Learning Cycle (as she wrote in her book "Peak Performance: Success In College And Beyond"). A paraphrased excerpt appears below.
Since the whole procedure documentation is but a part of the Systems Development Life Cycle (SDLC), one needs to know the latter in order to foster a good working relationship with the business process analyst (who will explain the "why's" and "how's") and the clients.
Speaking of clients, they also have their unique documentation and instruction requests like the flow of instruction, sustainability of instruction (or how your manuals give them the capability to conduct their own trainings) and the readability of the texts and figures (for older readers). After all, even geeks grow old.
While not all have thorough teaching backgrounds like I do, it is not at all impossible for anyone to be a writer of instructions. Just follow Sharon Ferrett's adaptation of [Carl] Jung's and [David] Kolb's Adult Learning Cycle (as she wrote in her book "Peak Performance: Success In College And Beyond"). A paraphrased excerpt appears below.
- Why do I want to learn this [app]?
- How does this [app] work?
- What does this [app] mean [for my job]?
- What other things can I do [with this app]?
- Who can I pass on this knowledge to [after the training has concluded]?
Since the whole procedure documentation is but a part of the Systems Development Life Cycle (SDLC), one needs to know the latter in order to foster a good working relationship with the business process analyst (who will explain the "why's" and "how's") and the clients.
Speaking of clients, they also have their unique documentation and instruction requests like the flow of instruction, sustainability of instruction (or how your manuals give them the capability to conduct their own trainings) and the readability of the texts and figures (for older readers). After all, even geeks grow old.
