I wouldn’t have thought that our documents would be used that way, at least not at this company, but it is. And that’s pretty cool.

I went to check out my current article list there to see how I was doing, and I’m surprised to see that I’m almost at the payout amount in earnings! (that’s $25, if you don’t know) AND, my top earners have me in the as either the #1 or #2 article for the category, which is amazing. So without further ado, I give you my top 5 list.

• #5 –> Why the NHL doesn’t enforce the helmet rule more stringently
• #4 –> Best and worst experiences with airlines
• #3 –> How to save money using balance transfer credit cards
• #2 –> Basic project tips for the freelance technical writer
• #1 –> How to fly safely

Now I’ve got only 14 articles up there, so it’s taken me a while to amass my mountain of $18.18, however I know there are writers on there that are earning a lot because they’ve got hundreds of articles on Helium.com. Of course they’re also well-written and well-promoted, which helps. I’ve only done some small promotion of my articles, however I find it interesting to see what my top 5 articles are with that little bit of work. (just think where I’d be if I’d been promoting them all the time!)

Have any of you used Helium.com? Are you enjoying your experience? And how about your earnings?

The STC is also offering other types of “help” to writers who would like to attend. Things like:

• The option to pay half your registration fee online and the other half onsite.
• A list of ideas you could present to your boss to see if your employer will pay for your attendance.
• A list of discounted hotels and transportation ideas.

Personally I have never attended the STC Tech Comm Summit, but I would definitely like to one of these days. You can be sure that I will be taking advantage of all the discounts (like registering early) to make sure I can go. Perhaps next year.

A former technical writing manager told me this a while back when our documentation team was struggling to produce consistent content for the new software release. And it would have been an acceptable reponse and exhortation to us, if we had an established style guide we could use while writing this content.

After having worked as a technical writer for almost 8 years now, style guides are more of a reference rather than a strict guideline for me, as they all tend to be fairly similar. For example, using italic formatting for screen names, or writing “click Done” instead of “click on the Done button”. So writing the existing content for this employer was a relatively easy task, however at this stage the software developers were completely revamping the application. And our tech writing manager wanted a new “tone” for the UI and Help content.

Wonderful – except we didn’t have a style guide that laid out all of the guidelines that he wanted us to follow!

Half of the team was new to the company, and the new “tone” was radically different from not only the existing style, but from standard tech writing practices. So it was new to everyone. Yet my manager just wanted us to muddle our way along, producing content as best we could.

This situation was frustrating for a number of reasons:

• I have personally written and/or maintained style guides at 3 different large software development companies, so I felt qualified to write up the new one for this company.
• My manager had me start writing up they style guide, but he only wanted me to focus on the UI terminology section. Which would have been fine, if he allowed me to schedule the rest of the style guide as well. I had the time to complete the full style guide, yet he vetoed my every request to do so.
• We writers kept tripping over each other and delaying each other’s work with email threads of the “Do we click a button or click on a button?” and “Should we apply bold formatting to page names?” variety.

In the end our team was quite late in delivering the content to the development teams for prototyping, and my manager was concerned about the quality of the content itself.

From this situation I’ve learned the following, which I think can apply to all technical writers (and I’m going to use a numbered list here even though you don’t need to follow these in a sequential order–other tech writers, you’ll know what I mean here. *wink*):

1. Creating a style guide before you write a single sentence of content will save you a lot of time, both for existing technical writers and new ones you bring on board during the content development.
2. Saving time at the beginning of the writing process means you’ll have more time later to revise or solicit input from other teams and departments.
3. Style guides help technical writers feel more confident about the content they’re producing, which in turn makes their writing even better.

So if you’re looking to decrease your writing time, and save your company some money, take the time to write a style guide (or at least update your existing one) before you start writing your content. Your writers and your users will thank you.

Contact Julia today if you need a new style guide written up, or if your existing one needs some revision. She’ll help you save time and money.

This is why the words you choose to use are important.

So here are my 3 proofreading tips for any technical writer out there:

1. Read it out loud. If it sounds too complicated, it probably is.
2. Let it marinate. Let your content sit for a few hours or days, if you can. Come back to it later when you haven’t been staring at it for the last 3 days.
3. Get another pair of eyes on it. A fresh perspective can be helpful. This one’s a little hard for the freelancer, but you can enlist the help of friends, family members or your significant other to help out.

That’s it, that’s all. Nothing too complicated or difficult about it. Three steps and your technical writing projects will be better for it. What are your proofreading tips? Do you do anything different?