Learning New Technology

Do You Have the Love? One of the joys of being a writer, and a technical writer in particular, is getting the opportunity to constantly learn new things and write about them. Do you love to learn? Hopefully you do, because as a technical writer you'll be learning new applications regularly. Part of learning is simply having the right attitude. Learning can be a challenge. It can take you out of your comfort zone. Lots of people in the workplace resist the challenge of learning new software or new equipment, but the technical writer doesn't have this option. You'll need to enjoy learning or think about a different career.

Ask Questions
Asking questions is a great way to learn. Getting a feel for whom to ask is a great skill to develop. While someone wise said that, "There are no dumb questions." sometimes there are bad places to ask good questions. Take S.M.E. for example. While your S.M.E. may be eager to explain the benefits of the latest piece of software, they'll get annoyed if you ask them what software is. If you're lost or have basic questions, try to get answers from friends outside your workplace, Internet research, and reading. Getting up to speed on a topic before talking to the S.M.E. lets them know you respect their time and are willing to do your homework.

At the same time, realizing that you have "dumb" questions can be an asset for you as a technical writer, because you'll remember that some users may have the same questions. The whole reason technical writing has grown as a field is that S.M.E. with an intimate knowledge of technology often can't step outside their own brain and speak to people with far less knowledge. So don't criticize yourself for having basic questions. Honor them. Remember that your users may have them too. Try, though, to answer them on your own before seeking expert help.

Get to Know your Learning Process

How do you like to learn? How do other people like to learn? When approaching a project like a user's manual, you may feel that the best way to start is by giving a lot of background or explanation about a product so that users can understand it before trying to use it. But is that the way you personally like to learn? The last time you brought home a computer, did you sit down with the manual before ever touching the computer, or did you grab the computer and see if you could start it up without ever touching the manual?

Most people would choose the second option. Most learners want to know the least amount they need to get a product up and running and only consult the manual if they are having trouble. Get to know your learning process, and ask others to see if your learning style matches or contrasts with theirs. If you get a new cell phone or mp3 player, observe yourself learning about it. How do you approach the process? How do you feel about the help its manufacturer offers?

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.

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. Interested in learning more? Why not take an online Technical Writing course?

Technical Writer as Beta Tester

The technical writer is often the first non-expert to learn to operate a new technology, and has the opportunity to spot bugs or glitches and bring them to the design team's attention before the production process goes further. Pay attention when something doesn't seem to work as it should. Bring it to the attention of your supervisor, or call in the S.M.E. You may find out that you aren't using the technology properly. This can be valuable information (if a little embarrassing to obtain) because if you are confused here, your user may be also. On the other hand, you may have spotted a bug that no one knew about. Bringing it to the attention of the rest of the team can mean getting it fixed before the product gets into the customers' hands.

Technical writers can also evaluate the product's interface with the user. Are the controls on a piece of equipment easy to find? Is the equipment comfortable to use? How smooth is the operation of a software interface? How many clicks does it take to get something done? Does any process seem too cumbersome? Bringing usability issues to the attention of the design team, if done with sensitivity and an open mind (no one LIKES criticism, so be fair), can improve the product. Ideally a technical writer will not focus strictly on writing a help manual but will participate in the development of a new product and will provide a perspective closer to that of the intended end user.

New Technology, Don't be a Witch Hunter

At the same time, the wise technical writer doesn't make it their mission to spot bugs. Don't ignore one if you find it, but don't approach a piece of equipment with the intention of finding out what's wrong with it. You may end up wasting time as well as alienating your coworkers. Assume that everyone wants the product to succeed, and that competent people have done their best to design it as well as possible given time and financial constraints. If you cannot believe this about the company and the product, this is a sign that you might want to look for another job.

Zen Mind, Beginner Mind

This phrase from Zen Buddhist meditation reminds practitioners that no matter how experienced they become, they should never lose the open, inquiring mindset they had when they first began. As a technical writer, you may become far more tech savvy than the average user for whom you will be writing. You must take care to remember what it's like to not be so comfortable with new technologies. That way no matter how much you know, you'll never lose your ability to communicate effectively with your users. As the Zen masters also teach, practice mindfulness. Be aware of your learning process as you learn. Be aware of the learning processes of others. As soon as you forget what it's like to not understand something, you will lose your ability to communicate with those who know less than you.