1. My day job keeps me too busy. This is my own personal demon that’s kept me from striking out as a freelancer. It’s the 100-pound gorilla on my back, the elephant in the room (pick your metaphor). So when the chance to go freelance finally presented itself last month, I took it. Jumped into the deep end with both feet and I’ve been loving every minute of it. Even though I’ve made a grand total of $5 so far, I haven’t had this much fun in years!
2. I’m not inspired to write. This is another tough one to battle, as we’ve all run into it. Whether it’s because you’re too tired from your day job, you’re sick, your kids or family take up too much of your time, sometimes inspiration is nowhere to be found. But this is when you’ve got to persevere and just do it. I’ve been trying to stick to a writing schedule, making sure I write something everyday.
3. I don’t have a niche topic to write about. This is an easy one to fix, even though you might think you are truly stuck for topics. Sit down with a blank pad of paper and a pen (or a blank text file on your computer, whichever works for you.) Think of three things you like to do. You could write “cook”, “eat”, and “play video games”. Good, now think of 5 more. Pull out your thesaurus and start looking up some of these words and see what other topics you can develop. Pretty soon your page will be full of ideas and topics for niches you can write about. Do a bit of research on the Web and see what sites or publications are out there for those topics. There you have it, you’ve discovered your niche topic, the things you like to write about. Chances are these are topics you’re passionate about, and have some knowledge about, so you can just start writing. So go ahead, start writing.
4. Web content writing is different than corporate writing, so I won’t be able to find work as a web writer. Another one that’s specific to me. I’ve worked as a technical writer for over 8 years in a corporate environment, so writing web content is definitely something I’ve not done “professionally”. BUT, I do consider myself a writer first, and a computer geek second, so between those two things I know I can figure it out. I do some research on web content writing, and I read blogs and articles…A LOT of blogs and articles. And I started writing posts on my own blogs (like this one), practicing the craft. While I know I’m not perfect, I think I’m getting the handle of it, and I know that as a good writer, I trust myself to be able to write whatever web content is needed, for either myself or a potential client. Plus I can use these posts as “clips” for job applications.

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?

Before we start, let’s go over a few concepts first.

What is a procedure?

A procedure is a set of steps that readers follow to achieve a specific end result. For example, you follow the steps in a recipe to bake chocolate chip cookies. Procedures are composed of steps or tasks.

What’s a task?

A task is a term technical writers use to refer to the smallest level of a procedure. For example, “Click the Save button” or “Open the File menu.”

The Breakdown

Now that you know what a procedure and a task are, let’s get back to the breakdown. Breaking down a topic into small enough chunks that you can create a procedure can sometimes be difficult, but if you use these steps, it’ll make things a little easier for you. In this example we’re going to talk about sending an email.

1. Think big.

This one’s usually the easiest step, since you’re probably already looking at a high-level topic like communication or whatever page of your software application you’re looking at. But in case you’re already at the low-level topic, you’ll have to take a few steps back and see where your it fits in to the larger picture. This could be as simple as thinking of your software’s target market, or a more general term for your topic. Our example: Communication

2. Ask questions.

Next, start asking yourself questions about the high-level topic. 3 to 5 questions work best, as this will help narrow your focus. Our example: How can I communicate using my computer?

3. Answer them yourself.

Look at your questions and try to answer them. Your answer is usually going to give you a clue as to what your procedure will be about. Our example: Using my email client, Send an email using my email client.

And there you have it, you’ve just broken down your topic into smaller chunks. Now you’re ready to write up the procedure itself, in this case “Sending email using my email client.”

Admit it, you thought it was going to take a lot longer, didn’t you? Of course the actual writing of the procedure might take you longer than coming up with the topic itself, and procedure writing has its own best practices and standards, but now you’ve focused in on what you’re going to write about. Good work.

• email overload
• information spelunking
• organic information sharing

Email Overload

The first issue, email overload, is a big one these days. Instead of simply phoning a colleague to ask a question, we send an email. This gets doubled if you’re dealing with colleagues in a different office in a different country. Then if you’ve got to copy your boss because of a change in a deadline, or some other issue that requires management notification, add another set of emails. And on it grows.

If you have a wiki, you can have a whole discussion on a topic right on the wiki page. Everyone sees everyone’s comments, so nothing’s duplicated, and in fact, even more of a discussion might occur because of something you might not have thought of. Depending on the wiki software you use, you might even be able to subscribe by RSS to the pages that you’re interested in, so you’re only notified when there’s an update to that topic. Very handy.

Information Spelunking

You know what this is, you’re looking for the answer to a question you have, and you’re not entirely sure where it’s stored on your department or company’s intranet. So you start searching, or spelunking rather, since typically there’s no structure to the sites you’re looking through. You end up spelunking through topics, pages, and sites with no success.

A well-structured wiki would help you focus your search and allow your users to find the information they need quickly. Determining the structure can be a time-consuming task at the outset, but it’s well-worth it for your colleagues in the end. It’ll save them time when they need to find information, and it’ll save everyone who’s got to share information time too, since they’ll know exactly where to put it.

Organic Information Sharing

Normally I don’t like to use terms like “organic” when talking about technical writing, but it’s just so apt here that I have to. What makes a wiki organic in terms of sharing is simply that everyone can contribute to a wiki. According to Wikipedia, a wiki is “a page or collection of Web pages designed to enable anyone who accesses it to contribute or modify content, using a simplified markup language.” As long as the structure is well-laid out at the beginning, and there are some style guide-type rules on how the information should be presented, then you’re all set to be organic.

A word of caution on the style guide-type rules though. Non-writers aren’t used to dealing with these types of restrictions, and they’re often not even used to sharing much information, so if you put too many restrictions on them, they’re not going to want to share at all. So the rules should be basic, like check for spelling & grammar, use some headings, that kind of thing. However it’s always a good idea to have a technical writer review the pages on a regular basis to catch things like this.

In the end,

wikis are a great way to promote information sharing, and to get everyone involved and invested in their work. In my opinion, technical writers are going to be called upon to manage these types of installations more and more, given the proliferation of online workers. It just makes things easier to transmit and share the information on a wiki. So as a technical writer, we’ve got to learn how to use these tools and master them, so that we’re ready for the next phase in our careers. While my own experience with wikis has been limited, I can see how they can become extremely useful tools to software development teams, and I look forward to working with them and seeing where they can take me.

Have any of you had good experiences with wikis in your work lives? Which wiki software do you like?