How Technical Writers Gather Information: Using the product

Getting to know a product is one of the keys to documenting that product. You “walk through” the various features and procedures and document them as you go. In some cases this is easy and in other cases it is difficult. Sometimes the product you are documenting does things that are outside of your level of experience or are based on complex sets of data and configurations.

For example, documenting a word processor gives you plenty of opportunities to explore. You can wotk with all of the standard features. Some of the more complex features may require specific information or applications, but every feature and is available (or should be). Additionally, because you are a writer, a word processor has you as one of its target users. Most of the features are ones that you would want to access and understand as an end user and that the applications designers would want you to access and understand.

Some products aren’t as easy to play with. For example, let’s say that you are documenting a program that links merchants, independent sales organizations (ISOs “eyesos”) and banks to a credit card processing system. Because you are a technical writer and thus are not a merchant, ISO, or a bank, this is not a program that has you as a target user. This means that the processes and features are not aimed at your skill set or goals. Much of the information you need to complete the tasks may not be readily available or easily replicated

If an application like this were being used to board an actual merchant, that merchant would have at least one merchant point-of-sale (POS) terminal to add to the system. There are dozens of different POS terminals that a merchant may choose from, and each has different data sets to be loaded. Some users may only be using the system for authorization and capture (front-end processing) while others may also use the program for clearing and settlement (back-end processing). For an extra, added level of difficulty, assume that the merchants, the ISOs and the banks all see a different version of the program, and that each may have any of 31 different configuration options that could change what they see on the screen. Also assume that you cannot use live data because that would give you access to sensitive information about a company’s finances as well as thousands of user’s credit card numbers. All of this, of course, assumes that the program is complete and operational when you are documenting it. Often features only become fully operational a week or two before the product rollout – which is about the time that the documentation is supposed to be available.

As you can see, while using the product is a key way to document the program, it can be difficult. Sometimes you have to use “dummy” or “scrubbed” data that has been designed to simulate the information you might actually use in the program. The problem with this is that dummy information is not real and it is not flexible. It can make accounting for every scenario difficult. In many cases, this is why you see documentation that is general and does not address all of your problems as a user. Often there are just too many scenarios and possible results to document.

Here are some tips to help you walk through a product:

• Get as much information beforehand as possible. You can often access functional designs or testing scripts that provide the process steps for you to work with.
• Consider the different types of users a product has and the different needs those users have.
• Try to simulate the actual user’s experiences and data as closely as possible.
• It is often good to walk through the program with other users or SMEs so that people with the appropriate knowledge or goals are on hand.
• Make mistakes. It is good to know what will happen if the user doesn’t do what they are expected to do.
• Take screen shots of applications while you work with them. You may or may not be able to use them in your documentation, but at minimum you can refer to them at times when you do not have access to the product.
• If something doesn’t function as designed, let the appropriate people know. Different companies have different processes for this, but sharing that information is vital to making the product work.
• Try out similar products if you have access to them. It is good to see how other products work with a user’s needs.

Does anyone else have any tips to add?

Part Three of a Series:

Part One: How Technical Writers Gather Information: Attending / Holding Meetings

Part Two: How Technical Writers Gather Information: Interviewing the SMEs