Feb 272016

I proposed this article at the End of Year celebration last June, after I graduated from the University of Massachusetts Dartmouth with my Master of Arts in Professional Writing. Earlier that month, I accepted the first job offer that came to me, a technical writing/documentation specialist position at Canary Systems, Inc.. Located in New London, New Hampshire, Canary Systems is a small company that creates instruments called dataloggers, which collect data from structures like dams and mines, and they relay the information back to users through a proprietary software suite, MultiLogger®, which manages an entire network of these dataloggers and their data.

I was excited to finally end my job search and I stood ready to take on the world. I moved from Connecticut to New Hampshire in early July and was prepared to begin my job. I walked in, built my own desk, received my laptop, and sat down, eagerly awaiting my first task. I quickly learned that I was going to have quite an ordeal.

My first few months were a trial by fire. Upon arriving, I learned the company had fallen behind on its documentation obligations, and that the documentation duties went to different people, like the company president or the software support engineer. My first task was to update the documentation for the 2014 release of MultiLogger, and I had to ideally have these updates in time for the 2015 release, which was scheduled for the end of August. In addition, I had to acquaint myself with MultiLogger and learn how to use it so I could properly document these features.

This was a tall order, and to compound the challenge, the subject matter experts I needed to talk to worked remotely and could only be in the office once a month at best. My solution was to sit down and learn the software with some of my co-workers, when they had the time to spare. I used what information I had to update the documentation. I was introduced to SnagIt, which I used to capture high-quality screenshots from the software to place in the user’s guides in Microsoft Word. Also, I learned how to create and edit help files in Doc-to-Help 2011. I improved the organization and readability of the user’s guides while I implemented the new information I learned from my own use of the software.

When I handed my first drafts of the user’s guides and help files to the subject-matter experts, they commented where I wrote information incorrectly. I thought I had the right information, from my coworkers and my own observations, but I missed documenting certain features that were not readily apparent. So I tried again until I reached an acceptable level of technical accuracy. Eventually, the user’s guides and help files were updated, albeit a month after the 2015 version was released.

As I began work on the 2015 documents in October, I needed to implement a structure so that they could be completed in a timely fashion. I decided that after I drafted a user’s guide, it would be sent for review of technical accuracy. Then, I would send that updated draft to the marketing director for readability. After I addressed all his comments, I would give a printed copy to the president, who would give a final review. Once he approved of the user’s guide, a PDF version could be put on our website. Because our help files are based on the user’s guide, I would wait until the user’s guide was complete before building the help file.

In addition to my documentation duties, I worked on pet projects to improve the company’s procedures. I created a style guide that would set standards for all software user’s guides. I and my successors would adhere to it and update it as necessary. I used the features in the current documents and incorporated them into the style guide. In addition, thanks to our chapter’s November 2015 program, I piloted a video tutorial workflow, helping fulfill the marketing director’s desire to create a library of videos.

Of the six user’s guides and three help files that accompany a software release, I have completed four of them, as of this writing, with a fifth undergoing revision. I also have completed one of the help files. I am now at the tail end of the 2015 documentation. Our 2016 release is coming up and I will have to change gears to update the documents to account for the new features by the time it launches in the spring.

The biggest challenge for me in this role is to speak up and suggest changes to the documentation workflow. I was skeptical about proposing new ideas to my president early on, as I did not want to rock the boat. Now that I’m six months in, I feel like I have enough experience to pitch new ideas to my president so that I can make a difference at the company.

I want to implement a document management system so that I don’t have to juggle versions of documents that sometimes don’t sync up properly. I want to hold reviewers more accountable to their tasks by checking in with them twice a week, so I can ensure timely feedback. I want to be more hands-on with the subject matter experts, so I can receive the knowledge I need, and they, in return, can see where the software can be improved. I want to set up a testing environment, so I can explore MultiLogger and recommend improvements to the user experience.

Finally, I will acquire more robust tools so that I can work with the information in a more versatile way. They would also improve my productivity and free up time for other tasks—creating video tutorials, updating the application notes, and maybe even updating the hardware documentation. When I attend the Summit in Anaheim, California this year, I will see what’s available and choose the one that fits our needs the best.

About the Author

Photo of Paul Duarte

Paul Duarte

Paul A. Duarte is a Documentation Specialist at Canary Systems in New London, New Hampshire. He holds an MA in Professional Writing from the University of Massachusetts Dartmouth. Paul is Vice President of the New England Chapter.