I love writing and I’ve been looking at ways to expand my audience, so I’ve been looking into freelance writing. But, man, there are a ton of freelance writing scams out there!

Some of the sites I found require an “application” or “registration” fee (e.g., freelancehomewriters.com). Really? Shouldn’t the site be making money from me writing for them? Then I found a lot of blogs and posts (e.g., freelancedaily.net, Scams, Warnings, Deadbeats) that actually document the scams as well as the deadbeats who just don’t pay for the work.

I found a pretty good eHow article about avoiding freelance writing scams; step 7 was pretty much number 1 for me:

If they ask you for money, then writer beware. The basic principle of any job is that the employer pays the employee, not the other way around.

Searching for information about freelance writing scams led me to Men with Pens and essentially an admonishment to save my money. Generally, if someone’s willing to share their “get rich quick” system with you for a “low-low price!”, it’s a scam: they’re getting rich by stealing your money!

My top 3:

• Suite 101
• Associated Content
• Helium

What are yours?

When a technical writer prepares to update or write new documentation, an audience analysis is probably one of the first things he does. Unfortunately, it involves a lot of guesswork. Does he want to interview users and get answers to his questions?

• What does the audience already know?
• What does the audience want to know?

Or can he proceed based on a few educated guesses?

What does the audience already know?

Really, does a user even know what he knows? How many interviews is a technical writer prepared to conduct to extract sufficient information from the audience?

What the technical writer is probably going to find out  is that some users are experts, some are novices and the rest are somewhere in between. So, how to write for the novice without condescending to the expert?

The easiest solution is simply to write for those in between: assume the user has seen the process and (a) either needs a short refresher or (b) will follow the documentation while performing the procedure. In either case, the documentation can be exactly the same.

What about other types of communications? The same process applies: the novice will need to read the communication in its entirety and the expert will be able to skim it for the important ideas.

What does the audience want to know?

But what information actually ends up in the documentation or communication? In a standard software user guide, for example:

• What does the software do?
• How to install or uninstall it?
• How to configure it?
• When to use its myriad functions?
• What to do about error or warning messages?
• Who to contact for support?

Yes, generally all of these questions need to be answered all the time.

But because the expert will probably know the background information, and because the novice won’t need it immediately to perform a procedure, it can be included in an appendix, if necessary. As well, by writing task-based procedures, all the users can follow the procedures to perform a specific task. An index will lead the user to the appropriate procedure related to a specific function. And a glossary will assist novices with unfamiliar terminology.

The audience analysis becomes much simpler once the basic concepts of the document are determined: a reasonable knowledge of the average user is sufficient to begin the documentation process. This should already be available based on the project and the reason for it.

Here are few resources for audience analysis:

• wikiHow: How to Conduct Audience Analysis
• Online Technical Writing: Audience Analysis
• Wikipedia: Audience analysis