Write Now ... in the world of Technical Communication - Technical Writing

Does Freelancing and Telecommuting Really Work?

Libby — Thu, 29 Jul 2010 18:08:57 GMT

I'm part of a couple different groups on LinkedIn. Recently, a thread was started entitled: "Hi All: Is working remotely a common situation for a technical writer who has a fulltime position in an organization."

The topic was posed by a college-level professor who teaches technical writing. From the sounds of it, she was wondering what to tell her students about this subject. There was a great community response from the post - lots of professionals posted their experiences, likes and desires. Since I'm a big fan of working remotely, I weighed in on the topic and I thought I'd also share my response here...

"I agree - while working remotely is becoming more common within technical writing, it is by no means normal or should be expected. One of the reasons I started my own freelance technical writing/training solutions company is to add more flexibility into my schedule. Writing in an 8-5 environment is often hard and I like the flexibility of being able to walk away for an hour or two then coming back and working until 9pm - essentially working to be productive instead of simply putting in "standard" work hours.

Being a freelancer takes the focus off of the hours you put in (I put in far more than 40 hour weeks!) and focuses more on results – often those results take more or less hours than you anticipated. I find I’m much more productive when I’m not required to put in X hours. A career coach once told me that you can stretch out any task to fill the hours. I’ve found this is so true! When you’re freelancing and building a solid client base, your time becomes much more valuable, thus you learn to be very productive with your time.

However, the declining economy has led me back to a more corporate setting and I was lucky enough to land a contract with a company who has an established work from home program. I work at least one day from home, sometimes two depending on the current projects (often more on various weeks if I'm working on training videos since the dept does not have the audio equipment & software set up I need to produce what they want.) I find that I don't like being away from the office more than 2 days a week - I lose touch with the ever-changing environment; and, unfortunately, the culture that exists at this organization still wonders if you actually "work" while you're at home.

To combat this, I try to target my home time for projects that are difficult to do in a cube setting - editing (because it's quiet) or writing (at times). And I make sure I'm available via the corporate IM solution just like I would be in the office. It does require a good amount of trust - and that trust has to be keep up long-term (at least within my current contract) as it is fragile. Once doubt enters into your manager’s head that you’re slacking off during work from home days, it is very hard to overcome; better to not let that doubt enter at all.

I was disappointed to read that some employers might think of a candidate as “high-maintenance” if they ask about working remotely in during an interview. When I interview, I strive to be honest and up-front about what I can do for the company and what I need to be a highly productive member of the team. Work from home is important as I live an hour a way from most major employers and a 2-hour commute daily makes it hard to keep a work-life balance and take care of my family. A strict M-F, 8-5 environment would be hard for me to work within long-term. Short-term it’s essential to learn about the new environment, product, project team, etc. Long-term, it would burn me out.

As for students or those new to technical writing, I think being on-site is ESSENTIAL for the first 2-5 years (or longer, depending). Especially for those coming out of college, working in a corporate environment can be overwhelming - the work & deadlines combined with the new social and political situations. You need to be on-site, listening, learning and being part of that culture so that you can learn how to continue to engage with that culture if you get the privilege of working off-site.

Working remotely is definitely an art - you have to learn how to do it effectively, make mistakes, learn from them and move on and be VERY conscious of your productivity and your interactions with your team and clients. My hope is that those of us who are successful freelancers and/or who work well outside a typical office setting continue to foster trust, be highly-productive and make a good name (so to speak) for working remotely within this industry."

If you have an opinion or questions about freelancing or working remotely, leave a comment, email me or join the LinkedIn group and post a message.

Power Publications: One Document, Multiple Uses

Libby — Tue, 06 Jul 2010 19:59:33 GMT

In today’s corporate culture, managers and executives are looking for more and more ways to minimize costs and maximize output. When it comes to technical publications (both print and interactive electronic), writers and designers need to think outside the box to author and design materials to suit a wide variety of uses.

Long gone are the days where you had a separate user manual (for reference), training manual (for users taking a class), quick reference guide (to use as a desk reference), governance policy, etc. Today, one publication or e-learning course should satisfy at least two or more training and knowledge transfer criteria. So how do you do this?

First, think about how each different type of publication will be used. To continue with my earlier example, user manuals are most often large, comprehensive reference manuals. Users go to them when they can’t figure out how to perform a specific topic. Sometimes new users are instructed to “read” the whole manual before they begin a job or task. (We all know users rarely read these publications cover to cover!)

A training manual is often more interactive as it’s generally used in a classroom or online learning environment. It may present the same information as a user manual (maybe even use the same exact content if the organization has a good content management system), but is supplemented with hands on activities or tasks a user should perform to familiarize themselves with the topic being discussed. These manuals are often more graphical or have more callouts, notes, and icons to help guide learners through each module.

Quick Reference Guides, cheat sheets and the like are often prized by users. They are generally short and concise and provide quick reminders about how to perform common tasks. Like the training manual and the user manual, these quick reference sheets may contain the EXACT same content as other publications within the organization. When you look at these three types of publications as a whole, it doesn’t seem like a very efficient documentation process.

So what if we combined a couple of these documents into one power publication? What you get is an extremely dynamic manual that has multiple uses within an organization. But how do you combine all that information into one format for different audiences?

Organization is a key factor when approaching a power publication. I’m currently working on a user guide for a software program that will also serve as the main training manual for instructor led (ILT) courses. The organization already knows that not everyone will be able to physically attend the classes but they wanted these users to have a similar learning experience.

Step 1: I started with the concept of a user manual. The first objective is to explain all the features and functionality of the software, top to bottom. This ensures the manual contains everything a user might want to know about how to use the program.

Step 2: I then added the organization-specific standards and governance policies regarding that software. This includes things like where to store reports a user creates, naming conventions, etc. This makes the manual extremely relevant for the users. They now only have to go one place to view the organization’s policies on tasks as well as view instructions on how to perform that specific task.

Step 3: Add in practice activities. In the current project, we call them Practice It! activities. The organization set up templates, sample reports and dashboards in a “training environment” within the software that all users have access to. In each section, we indicate how to use the templates or reports to practice, step by step, the steps for each task or process. Since the training environment uses real data, users get a good feel for how they might need to set up reports for their individual business units. These Practice It! exercises are also what the instructor uses during any ILT classes. Now users can get a similar learning experience without having to attend an actual class. To help users distinguish these practice exercises from the actual task step, we used a different font color/style and icon.

Step 4: Supplement the large user manual with a Quick Reference Guide. In the current project, we decided to keep the desk reference guide a separate publication to simplify distribution through the organization’s existing document management system. Some information is duplicated between the two publications, but the quick reference guide is much more succinct with more graphics and less text.

Step 5: Test and tweak. Documentation and training does not live in a vacuum. The beauty of creating training publications, reference documents and e-learning courses is that they are living creatures that change and grow with the organization. Test your initial format and be open to feedback. Change the document format, layout, and content so that it achieves all the initial goals.

This may seem like a lofty proposition for your publications, but your users and management will be ecstatic when it works well. And it saves you, the content developer and designer, a lot of time and effort in the long run which frees you up to work on more interesting projects rather than continually repurposing the same six documents over and over and over again!

P.S. – This same concept will work when combining documentation with e-learning courses. Walk your users through the key concepts. Let them try out the exercises and provide links to your existing (long, dry) user guides for when they need more information. This is one area where there are endless ways to creatively organize and offer your existing print and electronic content through an e-learning medium.

These are a few of My Favorite Blogs (and Newsletters and Magazines…)

Libby — Wed, 27 Jan 2010 22:30:28 GMT

Blogs… just about everyone’s got at least one these days. Some people I know subscribe to 20 or more. Some people say they don’t have time to read anything else besides the 100+ emails they get a day.

I have to admit – I was a late adopter of blogs, both reading and creating my own. While time is (always) a limiting factor, recently I’ve found some great tips, tricks and information from these blogs, newsletters, and publications.

The Rapid E-Learning Blog

I was hesitant about subscribing to this blog as I was worried it would be too product focused. (It’s produced by Articulate.) Instead, this blog focuses on creating rapid e-learning (hence the title) no matter what platform you use. The articles are well written and have some great tips.

Overall, I really like that this blog encourages instructional designers to reach out to others, even those using different platforms. They’ve had some great posts on fonts, PowerPoint Presentations, and using audio in courses, among other things. If you’re an instructional designer and are only looking for one new blog to subscribe to, this one is at the top of my list.

TechSmith Newsletter

Ok, so this isn’t actually a blog, but I’m recommending it anyway. It’s especially useful for anyone who uses TechSmith products like Snagit or Camtasia Studio. I’ve learned some great tips about these products (like their latest article on how to create great images). Plus, this newsletter allows you to customize the type of content you receive. Only want content on Snagit or Camtasia, just update your preferences.

Chief Learning Officer Magazine

This is a great magazine and website for anyone who’s interested in advancing their career within learning and development. Executives and upper management are the target audience for this publication, but I think the topics discussed here are valuable for anyone who is interested in the issues that L&D departments face.

I like that CLO articles gives me a 10,000 foot view of the learning and development. I often reference articles and tidbits I read in CLO when I talk with clients about developing training programs. CLO is talking about the big issues on learning executives’ minds and profiles Fortune 500 companies that are successfully navigating through the myriad of issues that so many L&D organizations face.

Right now these are a few of my favorites. If you have others, post a comment! I’m always looking for new reading material.

MS Word – Suppressing the “Space Before” on a Page Break

Libby — Wed, 13 Jan 2010 16:03:21 GMT

I’m a big fan of using styles when I author documents in MS Word. While I’ve generally found Styles to be the easiest way for me to produce consistent formats, I’ve always been frustrated with the non-native functionality of suppressing the “space before” settings when I insert a page break. Thus far, I’ve worked around this issue by using manual spaces (horrible, I know!).

Today, however, I decided I was tired workarounds. There must be a better way! A quick Google search led me to Allen Wyatt’s Word Tips. The article provided background about this issue as well as the location where you can adjust this setting (in Word 2003): Tools à Options à Compatibility Tab à “Suppress Space Before after a hard page or column break.”

Check the box next to the item then click OK.

Ta-da! Now when you insert a page break, the space before is suppressed. This ensures the first line on each page is in the same spot, no matter what type of style it is. (Typically my space before setting varies between headings and body styles. Previously, this resulted in varying alignments at the top of the page if I inserted a page break.)

A couple things to note:

Allen Wyatt’s article stated that checking this box didn’t fix the problem. He provides some good recommendations for what to do if this doesn’t work for you. Possibly an update to Word between the time he wrote his article and now fixed this functionality so it works as we expect.
For my environment, I’ve have to specifically set this property for each Word instance I open. It doesn’t seem to carryover to all new instances of Word.
For Word 2007, the Options window is access through the Office button.

Why I Love Being a Tech Writer

Libby — Wed, 23 Sep 2009 17:50:46 GMT

I often feel like I’m lucky for choosing a career that I (90% of the time) enjoy. When you’re young, in college and trying to figure out what you “want to be when you grow up,” often the choices are overwhelming. Maybe that’s why I took the long route (8 years) to complete my degree. I dropped out then went back part-time while working full-time in an effort to figure out what I wanted to do. It worked and (luckily) I was already on the right path with my current major (English).

I still feel like I got lucky – I choose a career that I’m genuinely passionate about. Some days you’re excited about getting that next project done or relieved that you’ve finally figured out to present a difficult concept. Other days, work is, well, work. You go. You write. You go home and do something more fun. (Writing is not always fun!)

This morning, I wasn’t sure what type of day it would be until about half way through my morning document development meeting. As I’m scribbling away on my note pad, trying to write down everything the developer was saying I was struck by one of those “This is why I love my job!” moments. Honestly, at this point in the meeting, I really had no idea how I was going to put all the information together. I was still struggling with understanding the concept. It was all slightly overwhelming.

Yet, I was loving it! I had a new, challenging puzzle to solve. (I’m fascinated with understanding how things work. One of my favorite TV shows is Modern Marvels on the History Channel because they take you behind the scenes and show you how things work.) As the development team talked through the concepts, drew and re-drew diagrams on the board, I frantically copied everything to my notes as well as chimed in to ask a few questions.

I have to admit as I walked out of the meeting I was still feeling overwhelmed. I had a basic understanding of the overall process and about six pages of notes about how all the pieces and parts fit together, but there were still a lot of loose ends and questions. Walking down the stairs back to my work area, I began thinking about how to present it. This project would be a fantastic candidate for a more interactive, online document where I could show the progression between each stage. Unfortunately, I’m limited to a static, PDF for the final version. Hmmm, that’s one puzzle to solve.

The second puzzle is how to explain all the information without providing too many details. One of the issues with the current documentation is that it provides too much information. The developers are getting confused; they’re asking too many questions because there is so much background information included. I need to present just enough information to explain the overall process but not too much. That will be a challenge.

Ultimately, I have to understand how everything works so I can present all the pieces and parts together into a coherent, useful document. That’s a challenge I always enjoy (partly because the process of organizing information is a puzzle in itself; it’s also because I love organizing things – just ask my husband out our linen closet.).

Challenges, puzzles and learning how things work – today those are just a few things that I love about being a tech writer.

Have you got a documentation puzzle to solve? Contact me! I’d love to work with you to understand and present the information in a way that’s beneficial to you and your business.

Oh, no! Another Acronym: Understanding IOB

Libby — Thu, 06 Aug 2009 17:18:06 GMT

In general, I’m always thinking about how to “prove” the documentation I craft adds value for the organization. Does it impact the bottom line? Does it reduce support costs? Does it promote employee efficiency? Plus, many clients feel conflicted about documentation, it is needed within their organization, but it’s hard to justify the costs especially in today’s economic climate.

This morning I was reading “Measure Smart: Trade ROI for IOB” published in this month’s edition of CLO magazine. At first, I was simply curious, “What is IOB?” Turns out, IOB, or Impact on Business, is an extension of ROI. Whereas most traditional ROI measurements focus on pure numbers, IOB looks at direct linkages between (in this case) training programs and business programs. Instead of looking at the total number of people trained, IOB focuses on changes in performance metrics after an employee completes a training program.

For example, say a customer service employee takes an interpersonal communication course. After the course, the number of complaints they receive are reduced (and they actually get a few compliments). Using IOB, the training department could say that the communication course improved that employee’s performance. They now have a more direct link between training and performance.

As I was reading, I thought the same concepts could be applied to technical writing. Like training, tech docs seek to convey knowledge to readers with the goal of teaching them something. And technical communicators are interested in those same metrics as training professionals – providing direct linkages between the documentation and business initiatives. “Hmmm, interesting,” I thought as I filed this tidbit of information away (for the next time a client asks about how we can do this).

The article also got me thinking about the future of technical communicators. As our field continues to evolve, we’re seeing a shift from printed documents to dynamic content. I have a feeling that in the coming years, technical communication professionals and training & development professionals will find more and more common ground as they face these similar challenges.

This is an exciting prospect! I think it will open new doors for all of us, especially those (like me) who enjoy elements within each discipline. I also think the increased collaboration between these two professions will enable us to develop more unique and concrete ways to evaluate the effectiveness of the materials we produce. Maybe, just maybe, IOB is the first step toward this future vision.

Reader-Centric Document Templates

Libby — Wed, 15 Jul 2009 21:44:24 GMT

A client recently asked me how I go about developing documentation templates. What principles guide my designs? Where did I learn how to design templates?

At first I didn’t know how to answer. Document layout techniques come naturally to me. Yes, I’ve had formal training on layout, font and color fundamentals. I do believe those help guide my design decisions; however, I often vary from these guidelines mostly to aid readability. Overall, I have one principle I adhere to when I’m designing templates:

Make sure the reader can use the completed document efficiently and effectively.

How I go about doing that is different for each client because each audience has its own unique characteristics. During your design phase, consider the following elements:

How will the document be accessed (online vs printed vs both)? Choose fonts, colors, and layout characteristics that work best for that medium.
If the document will be printed, is your employer/client doing the printing or the reader? This will affect your use of color, fonts and graphics as well as limit the page size.
What information is the reader looking for on the front page? Some documents may need a formal cover page while others may be more usable without one.
How will readers be referencing information within the document? Use organizational features such as a Table of Contents or Appendix to help readers find what they need quickly.
Finally, what other information must the document include? Incorporate information such as a document ID, publication date, security notice, etc. into the format so that it is not a distraction to the reader.

These are just a few things to take into consideration when designing a new document template. Be open to changes (even if you’ve been using the template awhile) and flexible with your design. Like the rest of the documentation process, templates change as the business and content needs change.

Technical Writing as a Noun or a Verb?

Libby — Thu, 09 Jul 2009 00:40:41 GMT

Technical Writers are not unique in their struggle to prove they “add value” to an organization. Currently, I’m working for a large, global client in their Enterprise Architecture division. While this client’s main business is not software development, because of the scope of their business they have invested significant resources to support the IT infrastructure and software they need to efficiently conduct their business efforts.

My current team’s challenge within Enterprise Architecture is helping the rest of the global organization understand what they do and why they do it. (Sound familiar?) Today, I was reading through some documentation about Enterprise Architecture based on research Gartner conducted. The particular document that caught my attention was one that was trying to provide a definition for Enterprise Architects.

The definition they crafted was well done – logical and comprehensive albeit a little clumsy simply because of the length (but at times you simply can’t avoid that). As I completed the paragraph, I thought they’d covered it all. Then they proceeded to explain that they needed to clarify a few points because of feedback from some of their customers and analysts.

As I read through their clarifications, I kept returning to the first point they stated: Their definition looks at an Enterprise Architect as a verb (i.e., someone who does something) rather than a noun (i.e., someone who produces things). I thought this distinction was significant, both to Enterprise Architects as well as to Technical Communicators.

It’s long been known that Technical Writers are most often viewed as “expenses” rather than “revenue generators.” While, in most cases, this is true, this view by the organization overlooks all the value that (good) Technical Writers bring to the table. Based on the Gartner article, I also have to wonder if some of this image is perpetuated by the fact that as writers, we are very focused on deliverables – concrete documents that prove we’ve been doing the work we say we’ve been doing. But what if there is more to it than that?

The Gartner article states (in the context of Enterprise Archicture):

“Our definition of enterprise architecture has focused on the ‘verb’ – because we feel it is important to emphasize the fact that enterprise architecture is a process. That is important because we find that often, when people focus on the outputs (‘the noun’) rather than the process, they tend to be more concerned about producing a predefined set of deliverables than they are about meeting the strategic imperatives of the enterprise. This single-minded focus on deliverables is a mistake because it can lead to mountains of ‘artifacts’ (requirements, models, principles, guidelines, standards) that are not necessarily connected to the strategic imperatives of the enterprise and are therefore not leveraged across the organization.”

Hmmm, that sounds an awfully lot like what we often do as Technical Communicators. Let’s look at this a little closer.

Technical communication is a process, something we engage in whether or not we produce anything. Think about all the time you spend talking (and listening) to people within your organization. We communicate technically when we work with users, editors, developers, HR or any individual within an organization. In that context, we are engaging in a process – we are communicating technical and non-technical information to an audience. Yet, when it comes time to relay to our boss what we “do” we often forget about these essential, daily actions.

We get bogged down in the numbers – completed documents/projects, new document initiatives, the total number of documents available to your organization. When passed up the chain, these numbers are just that, numbers. There is no direct correlation to the business. Thus, it’s easy for those removed from the process to discount what we do (produce documents) and eliminate that position so that funds can be reallocated to a department that easily shows direct impacts to bottom line business (such as sales). So what do we do?

I think we look at our positions at Technical Communicators more like Gartner looks at Enterprise Architects. Our job is not to produce but to facilitate. We are facilitating technical communication through documents, presentations, formal and informal conversations, company-wide standards, etc. We do more than just write – we assist the business with communication that supports the overall enterprise goals and objectives.

When we look at our jobs that way, it becomes much easier to align our daily activities with strategic corporate initiatives. We did not write a document simply because we were asked (or told) to. We crafted that communication to provide the sales team with an additional tool for their new sales strategy. We created that user manual, help text or tutorial to provide users with a reference tool which, in turn, cuts down on help desk related calls. We standardized how documentation is managed to help internal employees save time when searching for the reference they need.

By viewing ourselves and our role as active, verb-like participants, we not only help justify our place in an organization, but we also help make ourselves indispensible. So the next time you get bogged down in deadlines and document metrics, stop and ask yourself: “Are you a noun or a verb?”

Source: Gartner Clarified the Definition of the Term 'Enterprise Architecture'; Publication Date: 12 August 2008; ID #G0016559

Discovering Your Product's Voice

Libby — Thu, 14 May 2009 16:39:04 GMT

Writers often hear about “discovering your voice” when writing fiction. After all, the challenge of fiction writers is to craft a story that is compelling, interesting, and dynamic. Your characters must be likable; your readers must be able to relate to them or else they will simply set your story aside for something more interesting. The voice in fiction is often your character’s or narrator’s voice. It is that voice, the tone, the choice of words, how those words are arranged into sentences, that convey the deeper nuances within good fiction.

I am an avid reader. I revel in delightful, compelling fiction yet my attention can be equally captured by the solid, thought-provoking prose in a non-fiction novel. Good non-fiction has a compelling voice else there would be very few of us who continued to buy non-fiction.

Enter technical writing. Technical writing is non-fiction writing, yet many people (both companies and consumers alike) treat their technical documentation as an afterthought -“We have to document our product because we need to offer online help, user guides, etc. But we know our customers rarely use them.” Why is it that customer’s shy away from the technical documentation offered with products and services?

I think it comes down to voice. Let’s face it, most technical documents are boring. We, as technical writers, try to spice things up, but there are only so many ways you can say “Now, click Next.” Too often, companies are in a rush to get their documentation out with their products. This causes writers to rush – they do their best at getting the information down on paper but have little time to consider the voice of the whole publication. They’re just happy when they meet the ever looming deadline. The documentation gets out, hardly ever gets read, and customer service continues to receive the same types of calls in spite of those issues being thoroughly documented.

Now imagine how things might change if the application or service suddenly became a character. You’d still explain all the technical details about your product. You’d still include all the screen shots, tables and instructions, but the tone would be different. Your product would become the main character and, as such, it would have a distinctive voice. Maybe the voice is more familiar and includes current technology slang if your audience is of a younger generation. Perhaps the voice is more formal, but concise and friendly, for a corporate business audience. Either way, the product takes on its own persona. Your writers have the ability to include more details, tidbit, and side bars about how the application works, its quirks, and, ultimately, its power. The documentation becomes an extension of the product itself instead of simply an afterthought.

Once the documentation becomes an integral part of your product, you’ve opened up a whole new realm of possibilities. High-quality, comprehensive documentation, tutorials, and training materials can then become revenue-generating tools that could set you apart in your industry. Your documentation becomes an integral part of your business, driving sales and providing actual ROI to both you and your clients. Your customer service related calls are reduced. Your clients have more successful implementations and adoptions of your products. In short, you’ve reduced overhead while boosting sales – all because you discovered your product’s voice.