Over the weekend, a friend showed me an episode of a reality show that featured some commentary by a “style expert.” This expert offered his advice while dressed in an outfit that would work well as a costume in a production of Oliver Twist (and that’s being charitable).
I thought he looked ridiculous and even said to my friend, “Why is it that the people in the style industry can’t seem to dress themselves?” Sometimes, I feel like I’m looking at clothing designed by people on another planet when I see articles and videos about the latest styles.
This morning, I’ve been in much more familiar territory while reading two online conversations about a different kind of style: the application of style guides in technical communication. Scott Abel, Larry Kunz, Julio Vazquez, and others are having an excellent discussion about the purpose and value of style guides, and a posting on Technical Writing World asks about the best reference books for new technical writers.
So, what do style guides do in technical communication? I’m not going to rehash all the excellent points made by Scott, Larry, Julio, and others, but I will say this: I can get really persnickety about inconsistent terminology and other writing issues that style guides address. That concern about quality writing, however, is likely not shared by unhappy end users who are reading knowledge base articles, online help, or manuals to get help with annoying problems. Do you think those end users are looking for beautiful, pristine prose, or the answers to their questions? It’s the latter, I’m afraid, and it’s really painful for The Writer in me to admit that.
Can well-written content make it easier for people to comprehend an explanation of a problem? Absolutely. However, now that forums, blogs, and other social media outlets let everyone provide helpful tips on how to use technology, “decent” and “understandable” writing is often enough.
Those of us in technical communication now need to think about the business cases for style guides, and that means quantifying how the use of style guides affects effort and costs. How much money will consistent terminology and phrasing save on localization costs? Is there suitable software that can help enforce style at the time of content development, and if so, how much does that tool cost vs. the amount of effort it will save on downstream editing? These kinds of questions are tough to answer, and the answers will vary from organization to organization. Contributing to business case evaluations will make you more valuable to your employer. Therefore, I think it’s essential that technical communicators have the ability to address how the tools and processes (including style guides) we use help our employers’ bottom lines.
That sort of business-based thinking leads to the second style-centric conversation: what books should new technical writers read? Several people in that discussion (and other similar discussions I’ve seen lately) suggest style guides, such as The Chicago Manual of Style and the AP Stylebook. I’m very familiar with both books and appreciate their contributions to excellent writing, but I think we may be doing new technical writers a large disservice by recommending style guides as must-reads.
Instead, I think new technical communicators should focus on reading books about the processes and tools behind technical content: single sourcing, structured authoring, localization, the DITA standard, and so on. Writing ability is still very important: as someone who now makes hiring decisions, I consider it to be a prerequisite. However, I will look much more favorably on a candidate who can give me a basic explanation of structured authoring and its benefits over someone who can’t. Showing an understanding of how a process can reduce costs will likely give a job seeker an edge over other applicants.
Writing ability on its own just isn’t enough today in tech comm—these days, employers need (and expect) more: