Daniel Beck
Editor’s Note: This year, the STC Technical Editing SIG offered scholarships to one undergraduate and one graduate student in technical communication. One part of the scholarship application was to describe a project or research that the applicant was involved in. We asked the scholarship winners to write a newsletter article summarizing their project or research. This is the second of such articles from our undergraduate scholarship winner.
This past spring, I took the last in a series of technical writing courses offered here at the University of Central Florida (UCF), creatively titled “Technical Documentation.” Unlike the two previous courses in the series, I was set loose with minimal supervision. My objective for the semester was to find a client, propose a project, and complete the work of the project entirely on my own. The instructor in the course would only review my work and provide substantial feedback once, at the middle of the semester.
I felt that the class was a terrific opportunity to try something I hadn’t done before. I had missed some opportunities to work as an editor in my technical communication coursework. With this course, I had an opportunity to take advantage of and get some much-needed experience working with the results of other writers’ work.
My part-time employer, the UCF’s Course Development and Web Services, had just the project for me. They had some documentation that was in desperate need of revision. UCF was transitioning from one Web e-learning platform to another. It was a somewhat painful process that I’m sure many people are familiar with — after spending years using one tool, thousands of users were ushered on to another.
The difficulty of this change was exacerbated by the lack of well-maintained documentation. The documentation provided by the software vendor had not been updated in years; it only somewhat reflected the software in use on UCF’s servers. Furthermore, the documentation was internally inconsistent. Supplements to the documentation produced by Course Development and Web Services were visually and textually inconsistent with the vendor-supplied documentation.
Naturally, I chose to overextend myself that semester by trying to single-handedly solve all of these problems. It was a long, tiring process of reviewing hundreds of pages of instructions and attempting to coordinate their strengths and mitigate their weaknesses. Pages and pages had to be entirely rewritten; dozens of screenshots had to be recreated to match the software in use. And throughout it all, the details of the project were left up to me.
Of course, I learned some interesting practical lessons. For instance, I “discovered” — probably in much the same way that Columbus “discovered” the Americas — a cheap trick for testing documentation out on an audience. In the day-to-day activities at Course Development and Web Services, I often responded to support requests via email from faculty members. Frequently I used portions of my documentation revision project as the basis for responses to email questions. It was easy, cheap testing. Instead of writing up one-off instructions for the faculty, I would send them portions of the documentation. I got unambiguous feedback without ever having to convince any faculty members to complete a survey or an interview: either the documentation resolved the issue or didn’t.
I also learned that my weakness for playing with flashy new technology might someday be a problem for me. I committed myself early on in the project to use a new project management tool that Course Development and Web Services had purchased. It was fun to learn, but I think I spent more time figuring out the tool than actually using it to get the job done. As it turns out, one person doesn’t need a project management tool, one person just needs a to-do list. While working alone, I found that the project management software was overkill for the amount of tracking and reporting I needed to do. I could imagine such a tool being useful for a team of writers, but for me it was just a distraction.
But the most important lessons I learned had to do with what it actually means to be a technical writer or editor. As the semester dragged on, I began to appreciate what other technical writers mean when they refer to the “lone technical writer,” a phrase I had heard often, but didn’t fully understand, despite many STC chapter meetings and two Summits. There is so much value in having at least the camaraderie, if not the outright assistance, of other writers working with you.
And it was that lesson that ultimately led to a big realization as to what it is about technical communication that really appeals to me. The loneliness of being the “lone technical writer” let me finally figure out that it’s not about the writing. Though long hours in front of a keyboard, actually writing, can be fun, it’s not the point to write or edit for its own sake. Rather, the point is to reach out to others in a fascinating and productive way. Since I did not have the benefit of being in the same room as those potential other people, I learned to ask myself, again and again, how can I make what I do an improvement for me, a future writer or editor, my coworkers, and my audience?