1%

Points to Remember I


Watch others Learn




If you have an opportunity to watch other people learning, savor it. If your company has an existing help manual that you are trying to improve, get someone who is new to the product to try to learn how to use it. Do they refer to the manual? When? Can they find the information they need? Do they read anything or just look at the pictures? Make a mental note whenever you can about how people learn. It will help you immeasurably when you try to teach people to do something.

Relax

Constantly learning new things does have a downside for the technical writer. It can be exhausting and stressful, especially if a product is unusually complex, or if it's one whose nature doesn't allow you to learn to use it at all (a sophisticated piece of medical testing equipment, for instance), and you are dependent on S.M.E. for all your knowledge (and they're hard to track down or hard to deal with). Remember to give yourself a break. Take deep breaths. Stay in good physical shape. Realize that you can't always control every aspect of the project. Remain calm so that your temper doesn't get the best of you.

If you feel burned out while learning something, take a break. Move around. Answer some e-mails and then come back to it. Often there's only so much information a brain can process at a time. This is also something you can keep in mind when you write your manuals. Break up your text with illustrations and white space. Give your readers space to breathe. Break up sections so they can take a break or get a drink of water without losing their places in the manual.

Document your Learning Process

As you learn to understand and use a new technology, take the time to document your process. Keep a log as you go. Is this technology fairly similar to things you've learned before or are you undergoing a notable shift in your approach to understanding it? What aspects of this technology are the easiest to pick up and which are the most challenging? Where will you need to provide extra explanation in your documentation and where will you be able to get away with brevity?

Watch for Bugs

A bug is a glitch in the system, where for some reason, it doesn't work as it is supposed to. Technical writers who are getting familiar with new technology may be the first to spot a bug that has escaped the notice of the developers.



]]>