Developing Company Editing Standards
Click a link below to jump to a particular section; click any "
CONTENTS" image following a section heading to jump back here.
This presentation covers how to develop editing standards for content. It provides tips on how to get started when no conventions exist and how to improve coverage of topics when time and resources are limited. It describes how to get buy-in for editing standards from management and project members. This topic is of interest to all editors because pushback against editing changes is very common, and consistency is difficult to maintain without coworkers' buy-in to established standards.
Why Standards, Not Style?
Content development has changed considerably in recent years. While style is still important to editors, editorial perfection is generally not possible given time and resource constraints. Recent changes in the economy have also put pressure on editors to find ways to thrive in a world where style is not seen as a priority and the ratio of writers to editors keeps increasing.
One approach to standards that seems to work well for editors in technical fields is to leverage the name recognition of "standards" and to use it, in place of "style," when documenting content conventions. Engineers and other professionals tend to respect standards due to the existence of standards organizations like ISO, W3C, IEEE, IETF, and so on. Editors can piggy-back on this respect by placing greater emphasis on conventions that have technical impact. As described more below, general style conventions can be handled separately from standards in a number of ways.
Determining the Approach
The approach taken to developing standards can vary depending on the situation. It can also depend on the specific preferences of management regarding cost and time. Several approaches to creating a standards guide are possible:
- The straw man approach is the fastest because it involves delegating responsibility to one person to researchavailable resources and pull information from them quickly into a draft guide. While this approach might be quick, significant work is required later to unify, refine and streamline the different entries. The main disadvantage of this approach is that the guide can be a flashpoint for discontent and controversy if revision is not undertaken carefully and methodically.
- The ground-up approach is somewhat faster. Basically, this approach involves collaboration amongpeople who haveeach agreedto develop several entries. The benefit of this approach is that contributions from several people can speed up the process. The main disadvantage, though, is that it requires contributors to review content formany submitted entries at the same time.
- The organic approach is much slower, but ultimately the most satisfying, because entries grow along with the project. This approach involves pulling together a group of people to determine the most urgent issues. The group assigns one person to research the most urgent item and report back with a proposed entry. Once that item is complete, another person moveson to the next most urgent item. The main benefit of this approach is that entries tend to more accuratebecause they arethoroughly reviewed as they are written. The main disadvantage is that it takes time to be this thorough.
The time that it takes to develop a standards guide varies according to project. However, given the other demands that people typically have on their plate, it can take up to2 years to develop a fairly solid standards guide.
Determining the Scope
In addition to deciding on an approach for creating the standards guide, you'll need to consider what to document in the guide. A big danger is trying to be too comprehensive. Without determining the scope from the start, you run the risk of losing control of the content and not focusing on the essentials required for your project.
A useful approach in determining scope is to inventory the various information needed for your overall project (for example, document design, formatting, writing tips, word list, indexing conventions, global language, processes, workflows, legal requirements, QA check lists, and so on). Once you have the inventory, you can determine what guidance should go in the standards guide and what should appear elsewhere. For example, you might determine that processes and associated workflows should be housed on a SharePoint site in folders categorized according to the specific type of process. You might decide to skip legal requirements or globalization because the information already exists on the company intranet. Whenever possible, direct people to other available resources, such as those on an intranet, rather than repeating information that might change.
By being crystal clear as to what should go into the standards guide, you will be able to push back when other groups apply pressure to get their information in the guide. (For some reason, people tend to get really excited about contributing to standards guides!) Unbridled zeal and lack of planning can lead to poor content choices and a loss in focus for the guide.
If you have a particularly rich content library, you might need to go through the inventory process several times. For example, you might need a special standards guide for different audiences (such as, IT professionals, developers, end users, and architects in the software world). You might even need specialized guidance for different deliverables (book, Web site, marketing collateral, presentations, help files, and so on). Try to avoid having your standards guide be the be all and end all for everything you publish unless you work in a very small company or on a specific niche topic.
As alluded to above, style conventions can be handled in a number of different ways to distinguish them from standards. Here are some tips:
- Consider adopting a style manual as well as a dictionary to serve as resources for general conventions of English grammar, punctuation, usage, and so on. (The choice of a specific manual is outside this presentation, but you can find tips in Frick 2009.) Common style manuals are the Chicago Manual of Style, The Associated Press Style Book and Libel Manual, the MLA Handbook for Writers of Research Papers, and so on. A number of good dictionaries exist as well.
- If you cannot find style resources that fit your project's unique needs, you can create a style guide to supplement your standards guide. However, it may be that only a portion of your content really has a special need. In that case, you can create a style sheet specifically for that particular content and use the standards guide as a general resource for the rest.
The best way to ensure buy-in is to have management support. Because a standards guide potentially involves special funding, scheduling, and resource allocation, management needs to be in the loop and support the project.
It is especially important to have a robust means for people participating in the project to provide feedback. When people can provide input, they are less likely to complain later and push back.
In creating a process for standards, the following best practices should be considered:
- Appoint one person to be the project manager for the standards guide. This person is responsible for ensuring meetings take place, that issues get tracked, and that decisions make it in the guide. Either this person or the management sponsor should be designated as the having the final say during disputes or conflicts.
- Consider creating a committee to develop and review standards entries. The committee should be a representative selection of guide users who are able to review issues impartially. The context for a decision can be included in the guide if it provides useful background (for example, the context could be to meet legal guidelines, to comply with build requirements, and so on).
- Consider rotating new people into the committee over time, both in the project manager and member roles, to keep the number of people involved at a manageable level while providing differentpeople with opportunities for direct input.
- Provide a formal mechanism for submitting standards issues (such as a Web form, SharePoint site, and so on). Because e-mail threads can get long and convoluted, it helps to have a central repository for tracking, resolving, and closing issues.
- Consider carefully the format that your standards guide will use. The ability to search is especially critical to most standards guide users, so an online approach is often preferable.
- Provide a review period for all potential users before official publication of the standards guide. This might include a legal review if required by your company.
- Be sure to publicize the existence of the standards guide and subsequent updates. This can take the form of an e-mail or an announcement at a team or group meeting.
- Develop and publicize a regular schedule for updating the standards guide. It is better to publish at regular intervals than slip-stream changes with little or no announcement. Be sure to date each version of the guide and to maintain an archive of previous versions.
A standards guide can ensure consistency. It can save time (and, by extension, money) by serving as a repository for standards decisions and convention history. This is especially critical in a world where time and resources are tight and editors are continually pressed to do more with less.
- Allen, P.R. 1995. "Save Money with a Corporate Style Guide." Technical Communication 42, Second Quarter, 284-289.
- Ball, Valerie M. 2005. "Syntax or Sin Tax: Which Should an Editor Choose?" STC Conference Proceedings 2005.
- Corbett, Lori. 1996. "Polished Panache: The Empowered Corporate Style Guide." STC Conference Proceedings 1996.
- Dalton, Tracy. 2002. "Style Sheets: The Abbreviated Answer." STC Conference Proceedings 2002.
- Damrau, Jackie. 2005. "Developing a Corporate Style Guide." STC Conference Proceedings 2005.
- Flanders, Melanie G. 2000. "Who Needs a Style Guide?" Corrigo (Technical editing SIG), Volume 1, Number 3.
- Frick, Elizabeth G. (Bette) and Elizabeth A. (Betsey) Frick. 2009. "Style Manuals: The Politics of Selection." Intercom (November 2009), 9-12.
- Gelb, Janice and Jeffrey J. Gardiner. 1997. "Developing a Company Style Guide." STC Conference Proceedings 1997.
- Hart, Geoffrey J.S. 2000. "The Style Guide is 'Dead': Long Live the Dynamic Style Guide!" Intercom (March 2000), 12-17.
- Hart, Geoffrey J.S. 2002. "Editing with Style (Sheets)." Intercom (November 2002), 36-42.
- Quesenbery, W. 2001. "Building a Better Style Guide." URL: http://www.wqusability.com/articles/better-style-guide-paper.pdf
- Rude, Carolyn D. 2002. Technical Editing. 3rd edition. Allyn & Bacon Series in Technical Communication. New York, NY: Longman Publishers.
- Rydeski, Phillip J., Bryce A. Walat, and Julia LaSalle. 2005. "Making a Guide with Style: Web site, Web Site or website?" Intercom (April 2005), 14-15.
- Tarutz, Judith. 1992. Technical Editing. Reading, MA: Addison Wesley.
- Wilson, Chauncey. 2001. "Guidance on Style Guides: Lessons Learned." URL: http://www.stcsig.org/usability/newsletter/0104-style.html
This article first appeared in STC 2010 Technical Communications Summit Proceedings.
Kristine Haugseth has worked in the Technical Communications field for over 20 years. Although she has held different positions over the years, her first love and focus has been editing. She has been an editing manager for five groups at Microsoft and has contributed as a technical editor to several more. She has worked in a number of other roles at Microsoft, including documentation manager, project manager, and release manager. Kristine is the recipient of 10 STC awards in the Technical Publications category, both at the chapter and international level. She received the STC Associate Fellow Award in 2007. She is receiving the STC Fellow Award in 2010.
Content Publishing Manager
One Microsoft Way
Redmond, WA 98052
Copyright © 2010 WritersUA. All Rights Reserved.
shannonm *at* writersua *dot* com
Published on August 27, 2010
|WritersUA offers cutting-edge training and information to Technical Writers, Information Analysts and Architects, Documentation Designers, Help Authors, Publication Managers, Documentation Leads, Senior Writers and Documentation Contractors, and User Education Specialists. The focus is on software user assistance, which encompasses writing, editing, planning, coding, indexing, testing, programming, localization, and standards development.