technical editing as qa

APPLIED THEORY SUMMARY� Compares technical editing processes to

software testing processes� Describes content editing activities in the

context of comprehensive editing, usabilityediting, and copy editing

Technical Editing as Quality Assurance:

Adding Value to ContentMICHELLE CORBIN, PAT MOELL, AND MIKE BOYD

TRENDS IN THE FIELD OF TECHNICAL EDITING

Technical editing is sometimes perceived to besimply a matter of grammar checking and proof-reading. Perhaps fast-paced development envi-ronments, which often leave little time for editing

functions, contribute to this perception—or, more pre-cisely, this misperception. The levels-of-edit systems havehelped technical editors manage the editorial functions inthese hectic environments by providing a “frameworkwithin which editors can choose appropriate editorial tasksfor a particular document” (Nadziejka 1995, p. 278). Re-cently though, technical editors are focusing even more oncontent editing, collaborating closely with technical writerson developing high-quality information (Nadziejka 1999;Bush 2000a; Bush 2000b; Bush 2000c). Taking this progres-sion one step further, technical editing is beginning to beviewed as a quality assurance activity (Rude 2002; Hackos1994; and Tarutz 1992).

Using levels-of-edit systemsTo help manage their workloads, numerous technical ed-itors adopted the Levels of Edit system developed by VanBuren and Buehler (1980) at the Jet Propulsion Laboratory.Levels of edit are varying combinations of nine types ofediting tasks; these tasks range from substantive, language,and mechanical style edits to policy and coordination edits(Van Buren and Buehler 1980). In the last 20 years, manyorganizations have used these levels of edit to define theirown editing processes.

Haugen (1991) criticizes levels of edit, admittedly a usefultool for editors, as a way to limit the technical editor’s involve-ment in the information development process:

Although the intent was not to define editing for theprofession, in practice, the Levels of Edit has become asort of standard, nonetheless. The unfortunate reality,however, is that Van Buren and Buehler’s levels relyheavily on rule-based tasks, so the levels of edit tend tonarrow the conception of editing to largely rule-basedactivities. (p. 60)

Bush and Campbell (1995) suggest that levels-of-edit sys-tems help only in determining the cost of editing, not inassigning the tasks of editing.

The original levels-of-edit system has not always beeneasy to apply to other environments, leading many orga-nizations to modify the system for their needs. Prono andcolleagues (1998) recently reported on a 2-year study, theresult of which was a revision of their original levels of editto three simple levels: proofreading edit, grammar edit, andfull edit. Anderson and colleagues (1998) reported howthey used a levels-of-edit system specifically designed forediting a Web site and discovered additional responsibili-ties for the editor, while clearly defining the work to bedone at each stage of the project.

The most notable revision of the levels-of-edit system,however, is Nadziejka’s (1999), which addresses technicalcontent at each of the three levels. He completely turns thefocus away from grammar and style and toward the con-tent. His levels are not sequential, but independent of oneanother. Even the lowest level of editing, which he calls theRush Edit, remains completely focused on content.

Focusing on the contentNadziejka (1999) presents his content-focused levels-of-edit system in a book published by the Council of Biolog-ical Editors; however, he clearly states that

For technical documents (by which is meant intellec-tual, scholarly, or highly complex documents in anyfield), the primary focus must be to help ensure that thetechnical content is complete, accurate, and under-standable to the intended audience. (p. 5)

Grove (1994) agrees that technical editors need tomove away from mechanical editing toward comprehen-sive editing focusing on “technical content, completeness,

Manuscript received 18 July 2001; revised 3 March 2002;accepted 4 March 2002.

286 TechnicalCOMMUNICATION • Volume 49, Number 3, August 2002

and coherence” (p. 171). Since the 1980s, Bush (1981) hasbeen encouraging technical editors to focus on content, to“improve the readability of the documents and the techni-cal content of the information” (p. 16). In his FriendlyEditor column that appeared first in Technical communi-cation and later in Intercom, Bush has extolled the benefitsand necessity of content editing and stated that, indeed, hiscareer has focused on content editing (Bush 2000a; Bush2000b; Bush 2000c). Bush reiterates that content editinggoes beyond policing correctness; it focuses on clarifyingcontent. Technical editing clearly is starting to be perceivedmore as content checking than as merely grammar check-ing. This content editing brings a “technical quality” to theinformation, instead of just an “editorial quality” (Nadziejka1995, p. 283).

Technical editing as quality assuranceWith more focus on content editing, technical editingcan be seen as a quality assurance process. Mead (1998)discusses benchmarks for documentation costs, suggest-ing that one such benchmark is a “quality assuranceratio” that takes into account the amount of editing timein relation to writing time. In a software developmentenvironment, he also suggests that the quality of thedocumentation reflects on the customers’ perceptions ofthe quality of the software product itself. Technical ed-itors play a large role in ensuring that quality. Hackos(1994) states as one of her guidelines for managingdocumentation projects, “Work hard to institute [techni-cal] editing as the single most important quality assur-ance mechanism in the publications-development lifecycle” (p. 376).

In a software development environment, quality assur-ance is part of the software testing environment. Softwaretesters ensure the quality of the code that is written bycomputer programmers. Within this software developmentenvironment, comparisons have been made between tech-nical writers and computer programmers. As Bresko (1991)states,

Many similarities exist between computer programmingand technical writing. For example, in the compositionprocess for both programs and documents, programmersand technical writers gather all available, pertinentmaterials and begin writing in a logical order accord-ing to the rules of the language they are using. Thedifference is in the language and audience. Program-mers write programming code for the computer to inter-pret and writers write words and sentences for theirreaders to interpret. (p. 218)

This comparison could be extended to assert that tech-nical editing—and content editing in particular—provides

the same quality assurance processes for technical infor-mation that software testing does for programming code.Just as a software product is not released without goingthrough various software tests, product information (in theform of books, online help systems, Web sites, individualtopics, and so on) should not be released without beingsubject to technical edits.

In this article, we review the typical software testingactivities and then compare those activities to technicalediting activities. This article shows that by providing qual-ity assurance through content editing, technical editors addvalue to the information development process and help togive users the quality content that they deserve.

OVERVIEW OF SOFTWARE TESTINGOver the past 30 years, software testing has emerged as acritical part of the software development process. Softwarehas become increasingly complex and has grown in size.To match that growth, software testing organizations, alongwith software testing methods and standards, haveemerged (Kit 1995). The Institute of Electrical and Electron-ics Engineers (IEEE®) includes technical committees andstandards boards that develop these standards in conjunc-tion with software testing practitioners. These standardsoften are approved and adopted by the American NationalStandards Institute, better known to most by its acronymANSI (Kit 1995).

Software testers are paired with software developers tocreate solid and usable software (Chillarege 1999). Soft-ware engineering best practices show that software devel-opers work in tandem with software testers to produce thebest quality product possible.

Software testing is the process of using the software toensure that it meets established specifications and runs invarious environments (Whittaker 2000). Kit describes theprocess of software testing as consisting of complementaryprocesses of verification testing and validation testing (Kit1995). These software testing processes must be “integrat-ed at the most effective points in the development lifecycle” (Kit 1995, p. 26).

Verification testing is the process of reviewing require-ment specifications, design specifications, and the code.During verification testing, testers use formal inspections orinformal walk-throughs to review both the specificationsand the early versions of the software product so that theycan determine whether the software product and specifi-

With more focus on contentediting, technical editing can be

seen as a quality assurance process.

APPLIED THEORYTechnical Editing as Quality AssuranceCorbin, Moell, and Boyd

Volume 49, Number 3, August 2002 • TechnicalCOMMUNICATION 287

cations satisfy the customer requirements (Kit 1995).Validation testing is the process of evaluating the soft-

ware to determine whether it meets those specifications.During validation testing, testers use both low-level andhigh-level testing procedures. Low-level testing includesthese types of tasks:

� Unit testing, in which the developers test an indi-vidual component of a software product to identifyany discrepancies between the specifications and theactual behavior of the component (Kit 1995).

� Integration testing, in which developers and testerstypically combine individual components of a softwareproduct to discover errors in the interfaces between thecomponents (Kit 1995). For example, they determinehow well the components work together or if onecomponent causes a problem for other components.High-level testing includes the following types of test-

ing:� Usability testing, in which testers or human factors

engineers identify how the typical users interact withthe user interfaces of the software product, includingits documentation, for characteristics such as accessi-bility, responsiveness, efficiency, and comprehensi-bility (Kit 1995). For example, testers watch a personuse the online help. The usability test fails if a per-son tries several different ways of locating informa-tion but still cannot find the required topic.

� Function testing, in which testers identify discrepan-cies between the functional specifications of a softwareproduct and its actual behavior (Kit 1995). For exam-ple, the specifications say that users can print a datatable. The function test fails if the tester looks at thescreen display and sees no Print button or if the testerpresses Ctrl�P but does not get a response.

� System testing, in which testers take the perspec-tive of the users and determine whether the softwareproduct meets the original specifications. Systemtesting includes activities such as stress testing, secu-rity testing, performance testing, configuration test-ing, installation testing, recovery testing, serviceabil-ity testing, and reliability testing (Kit 1995).Software testers add value to the software product by

discovering errors and getting them on the table as earlyas possible; to save the developers from building productsbased on error-ridden sources, to ensure the marketingpeople can deliver what the customer wants, and toensure management gets the bottom line on the qualityand finance they are looking for. (Kit 1995, p. 23)

In summary, software testers add value by ensuringthat the product meets the expectations of the users.

TECHNICAL EDITORS AS ADVOCATES FORQUALITY TECHNICAL INFORMATIONMuch as the software tester is responsible for the qualityof the software product’s content, the technical editor isresponsible for the quality of the information content inwhatever format it appears. And what does quality ininformation mean? Hargis and colleagues (1998) identi-fied several quality characteristics: accuracy, clarity,completeness, organization, retrievability, style, task ori-entation, and visual effectiveness. Simply put, the con-cept of quality applied to technical information meansthat the information meets the users’ needs by providingthe right information at the right time. This goal ofquality technical information can be accomplished onlyif the information is:

� Easily understood by the users� Easily retrieved by the users� Well-written, complete, and technically accurate

The technical editor ensures that these requirementsare met. The technical editor is an advocate for the lan-guage, the company, the writers, and, most importantly,the users (Bush and Campbell 1995).

As an advocate for the language, the technical editormust have a strong foundation in grammar and usage. Thetechnical editor copy edits the document at the sentencelevel. In addition, the technical editor checks for complete-ness, appropriateness of the language for the audience,logical structure, effective organizational flow, clarity, andconciseness.

As an advocate for the company, the technical editorchecks for compliance to company style standards, legalcorrectness, safety and security (liability) issues, appropri-ate use of product names and trademarks, permissions touse borrowed data or text, and so on. The technical editoralso ensures that copyrights are correct, that product infor-mation is not disclosed prematurely, and that appropriatedisclaimers and copyright notices accompany different ver-sions of the information.

As an advocate for the writer, the technical editor ispart of the information development team. Technical edi-tors get involved early in the process with writers andbecome collaborators with them in their work. In informa-tion development, the technical editor helps the writer with

Simply put, the concept of qualityapplied to technical information

means that the information meetsthe users’ needs by providing the

right information at the right time.

APPLIED THEORYTechnical Editing as Quality Assurance Corbin, Moell, and Boyd


templates, information models, style sheets, and repeated(or common) text. The technical editor uses languageskills, writing skills, and information design skills to helpbring clarity and cohesion to the writers’ work.

As an advocate for the users, the technical editor fol-lows the instructions written by the technical writer andpoints out areas of difficulty. The technical editor is a goodusability tester who reads the information, performs thetasks, and tries to find holes, errors, or ambiguities. Thetechnical editor checks for appropriateness of the exam-ples and graphics for international audiences. Also, thetechnical editor is a second check on the technical accuracyof the information. The technical editor helps make theinformation more concise for the users, paring the text to itsessentials, eliminating technical jargon and unnecessarydetails, as well as eliminating marketing-related materialwhen that type of information does not belong in thedeliverables. Finally, the technical editor focuses on theindex, the table of contents, and other access and naviga-tional methods that can help the users to find content easilyand to understand its context.

SOFTWARE TESTING AND TECHNICAL EDITINGBoth software testers and technical editors focus on qualityassurance activities. While technical editors perform bothverification testing activities and validation testing activi-ties, the most striking similarities are in the validation test-ing activities. These validation testing activities (unit test-ing, integration testing, usability testing, function testing,and system testing) are very similar to the following tech-nical editing activities:

� Comprehensive editing, in which the editor re-views the content, organization, and design of theinformation to ensure that the reader can understandit easily and that the information meets its objectives(Rude 2002). The editor works closely with thewriter to develop the information completely byadding, removing, and revising the information asnecessary. Comprehensive editing is sometimescalled developmental editing or substantive editing.While the terms are different, the activities per-formed during a comprehensive edit are nearly al-ways the same.

� Usability editing, in which the editor becomes thefirst user of the information, reading and respondingas a typical user might respond to the information(Tarutz 1992; Soderston 1985). The editor uses thetable of contents, the index, the procedures, and thecommands, and verifies that each entry is correctand that there are no misunderstandings or misrep-resentations. Usability editing has its roots in usabil-ity testing and is particularly valuable when usabilitytesting might not be available or viable for the infor-

mation being reviewed. Some might consider usabil-ity editing part of comprehensive editing, while oth-ers might consider it an extension of copy editing,but it is clearly a distinct type of editing that a tech-nical editor performs to improve the quality and us-ability of the information.

� Copy editing, in which the editor reviews the para-graphs, the sentences, and the words for spelling,punctuation, and grammatical errors. The editor usesthe appropriate style guides to ensure that the docu-ment is accurate, complete, and consistent.“When most people hear the word editing, they think

of the activities that fall under copy editing” (Tarutz 1992,p. 87). However, technical editing is much more than justcopy editing. At every stage of the information develop-ment process, the technical editor focuses on the content toensure the quality of that information. Each of these editingactivities (comprehensive editing, usability editing, andcopy editing) includes content editing.

In the sections that follow, we outline specific contentediting activities within these editing activities, showinghow they are all quality assurance activities (see Table 1).

Comprehensive editingAs advocates for the user, technical editors focus their time,their talent, and their attention on the content of the infor-mation. They engage in the content, like a software testerperforming system testing activities, thinking about howthe information helps users complete their tasks. Early inthe development cycle, technical editors perform compre-hensive editing to improve the accuracy, clarity, and acces-sibility of the information. “The objective is to make themost extensive changes at the earliest stage possible, be-cause the later the change, the higher the costs and thegreater the risk to the schedule” (Tarutz 1992, p. 71). Also,Rude (1987) points out that comprehensive editing “[in-creases] the chances that the editing will be purposefulrather than reactive, and thoughtful rather than arbitrary”(p. RET-144).

As an advocate for the company (and the users), tech-nical editors must carefully review the information specifi-cations so that they can ensure that the appropriate infor-mation is available and that the information follows thosespecifications. Technical editors often help create the in-formation specifications, serving as information architectsand helping plan the product’s documentation sets (Tarutz

At every draft, technical editorsfocus on the structure

and organization.



1992). As the early drafts of the information are developed,technical editors review the outlines and whatever portionsof the information are available. Rosenquist (2001) reportsin her surveys that editors can catch structural flaws early inthe development cycle, thus improving quality and reduc-ing costs, because additions and changes are not perpetu-ated within an already flawed structure.

At every draft, technical editors focus on the structureand organization. The process of comprehensive editing“is, even more than a meticulous process, an intellectualprocess, requiring in-depth reading of the manuscript withall the technical knowledge the editor can bring to bear”(Nadziejka 1995, p. 280). This type of evaluation is similarto the integration testing that software testers perform.Henry (1998) describes this type of comprehensive editingas an “integration evaluation,” in which editors evaluateevery information element as part of the integrated soft-ware system, confirming the information architecture andproviding answers to many usability questions.

When technical editors perform comprehensive edit-ing, they engage in many types of quality assurance activ-ities. We will focus on the following content editing activ-ities that are part of comprehensive editing:

� Ensuring technical accuracy� Understanding and working toward the big picture� Reducing the amount of unnecessary information� Re-using information� Customizing information for different software solutions� Enabling continuous improvement Ensuring techni-

cal accuracy

Ensuring technical accuracy Perhaps the most impor-tant duty of an editor is “to make the language . . . conformto the actual facts” (Bush and Campbell 1995, p. 11). Bushencourages technical editors to move away from a focus ongrammatical correctness toward content correctness.

As we all know, the main writing problem is not incor-rectness, or even awkwardness. It is a massive blockageof information transfer, imposed by thoughtless organi-zation, skewed structure, and misplaced emphasis,along with stultifying wordiness and gross imprecisionin thought. (Bush 1981, p. 15)

While ensuring the technical accuracy of the information isnot a new trend, it has become even more important for

TABLE 1: MAPPING TECHNICAL EDITING ACTIVITIES TO VALIDATION TESTING ACTIVITIES

Type of Validation Testing Type of Technical Editing

System testingIntegration testingUnit testing

Comprehensive EditingComprehensive editing can include these types of quality assurance activities:

� Ensuring technical accuracy� Understanding and working toward the big picture� Reducing the amount of information� Re-using information� Customizing information for different software solutions� Enabling continuous improvement

Usability testing Usability Editing

Usability editing can include these types of quality assurance activities:� Ensuring that the information can be easily retrieved� Making the information accessible to all users� Understanding the users well enough to make appropriate decisions about style

and content

Function testingUnit testing

Copy Editing

Copy editing can include these types of quality assurance activities:� Ensuring that the information can be easily understood� Standardizing information written by multiple writers� Verifying each information deliverable



these reasons:� Our litigious society encourages companies and cli-

ents to sue suppliers that provide inaccurate infor-mation.

� Sales now are sometimes won or lost based on thequality of the information provided with the soft-ware.

� Software is returned because users cannot install oruse it. If the product or its information is inaccurate,it is difficult for the user to even begin using theproduct.The first line of defense in ensuring technical accuracy

is the software development team: developers, testers,technical support personnel, marketing personnel, writers,and so on. The second line of defense is the technicaleditor, who checks for consistency and accuracy in termi-nology, user interfaces, product names, inputs producingthe specified outputs, and so on. According to Tarutz(1992), part of the technical editor’s job is to do an accuracyedit, checking for contradictions and discrepancies in theinformation. Nadziejka (1999) also requires that technicaleditors verify that “statements are factually correct andlogically sound” (p. 14).

To perform useful and appropriate edits, technical ed-itors must be knowledgeable enough about the subjectmatter so as not to create inaccuracies in the informationwith their editorial comments. “The more you know abouta subject, the better you’ll be able to ask intelligent ques-tions. If you know the answers, that’s better still” (Tarutz1992, p. 101). However, technical editors must constantlyremind themselves about what the user knows and doesn’tknow, so that the information meets the needs of the userand the user can understand the information that is pro-vided.

Understanding and working toward the big pictureWhether technical editors work in a single-sourcing envi-ronment (where topics are re-used and delivered in multi-ple information deliverables) or in a more traditional infor-mation development environment (where books and

online help systems are the norm), technical editors musthave a clear vision of the “big picture.” As Grove (1994)states,

General knowledge enables the editor to be detachedenough to see the big picture, to understand how theparts fit together. Whereas analytical skills help the ed-itor separate the parts, general knowledge helps the ed-itor put them together. Having both these attributes, theeditor is able to see both the forest and the trees. (p. 173)

Technical editors must know how each informationdeliverable fits with the others, and they must know theusers and how those users work with the software. Whentechnical editors make “changes in words or sentences,editors must be careful to consider the paragraph, or attimes the entire page, to be sure the changes fit into thebig picture” (Bush and Campbell 1995, p. 11). The larg-est part of a comprehensive edit, according to Tarutz(1992), is ensuring that the information is organized intoa coherent whole so that the users can find the answersquickly.

Reducing the amount of unnecessary informationOften, technical writers tend to include too many detailsand too much repetition. Developers and subject matterexperts frequently want to tell everything there is to knowabout a function, while users only want to know enoughto get the job done. Technical writers filter out some ofthis information, but technical editors must finish the job.Hargis and colleagues (1998) recommend finding a balancebetween enough information and the necessary informa-tion. Technical editors consider the needs of the users andconsider precisely what they need to know to get back ontask. “In today’s usability designs, less is more, and aneditor may be the ideal person to make sure that everythingstated is required and oriented to the users’ needs” (Bush2001, p. 43).

The minimalist writing approach, as outlined byCarroll, urged writers and designers to let users do more,read less, and experience fewer errors (Carroll 1990). Mini-malism is not a simple theory of brevity or incompleteinformation systems, but rather uses research results tosuggest ways of supporting users in a learning environmentby providing action-oriented, task-oriented, user-oriented,and error-prevention information (Carroll and van der Meij1996, p. 84).

Bush and Campbell (1995) dedicate an entire chapterin their book to cutting copy and reducing wordiness in acareful and thoughtful manner. Again, the focus remains onwhat users need to understand to be able to perform theirtasks. An added benefit of reducing the amount of infor-mation is a reduced cost in producing the information.

To perform useful and appropriateedits, technical editors must be

knowledgeable enough about thesubject matter so as not to createinaccuracies in the informationwith their editorial comments.



Re-using information A company’s information set,both internal and external, is one of its most valuableassets. In today’s software development environment, in-formation development teams must look to knowledgemanagement solutions, which allow the teams to re-useinformation and to keep pace with the shortening softwaredevelopment cycles. Information must be written once anddelivered multiple times, in multiple media. Instead ofproducing books, writers essentially are producing topicsthat are combined to create help systems, Web sites, trou-bleshooting guides, and sometimes books. This modularapproach parallels the object-oriented approach to pro-gramming, where individual functions are created in mod-ules of code that can be re-used in several different soft-ware programs.

When these topics are combined to create an informa-tion deliverable, technical editors step in as advocates forthe users and help make that deliverable understandableand usable. For example, when a topic or set of topics iscreated for re-use, it is often stripped of its context (so thatit can be used in multiple contexts). Technical editors mustensure that the topics remain usable in each new context.Rockley (2001) says,

Many organizations have reduced or eliminated the roleof the editor. However, single-sourcing makes this rolean important one to ensure that information can bere-used effectively. . . . It is particularly important thateditors not just look at the words, but look at the use ofinformation to ensure that it is effectively written to meetcustomer needs. (p. 193)

This new single-sourcing environment brings newchallenges to the technical editor:

� Information must be usable and appropriate in bothprinted and online formats.

� Cross referenced information must make sense inboth printed and online formats, such that cross-references with page numbers occur in printed infor-mation and hypertext links in appropriate phrasesoccur in online information.

� Topics must be self-contained and thus able to standalone.

� Topics must be understood when they are linkedtogether from different paths through the informa-tion.

� Transitions need to occur between the self-containedtopics.Much like software testers performing unit testing and

integration testing, technical editors review the topics assoon as they are written and continue to review the groupsof topics as they are being developed. At the beginning ofthe information development cycle, technical editors can

assist the writers in creating templates along with a well-structured prototype (or model) to ensure that topics areindeed reusable. Technical editors also can determinewhether information is repeated across multiple topics andcan suggest additional ways to re-use the repeated (orcommon) information.

Customizing information for different software solu-tions As software is developed using object-orientedprogramming techniques, and as the resulting objectsare combined to create new or customer-customizedsoftware solutions, the information for those softwaresolutions must be created just as quickly and easily. As aresult, sometimes information developers must take theexisting set of topics and wrap industry-specific infor-mation around them. Such an approach is particularlyneeded when different industries use different terms torefer to the same concepts. Throughout the informationdevelopment cycle, technical editors use the productspecifications and their knowledge of the audiences forthese customized solutions to

� Ensure that the appropriate terminology is used forthe audience

� Test the navigational paths through the informationto ensure it makes sense to the users

� Review the information for cohesion and clear tran-sitions so that users are unaware that different prod-ucts or modules are being combined

� Confirm that comprehension of each topic does notdepend on the presence of a topic that has beendeleted in the customization process

Enabling continuous improvement Part of compre-hensive editing is performing the appropriate edits withinthe time allowed. Technical editors must have excellentproject management skills to keep track of the informationand the level of editing that has been performed on thatinformation. In extremely tight schedules, technical editorsperform policy edits, focusing on such issues as legal require-ments, trademarks and copyrights, and so on. Then, as time

Technical editors cannot replacethe usefulness of actual usability

testing; however, they canstand in for the users

by becoming the “first users”of the information.



allows or when the next release of the information is planned,technical editors can schedule the appropriate content editsand copy edits for the information. As Nadziejka (1995) sug-gests, comprehensive editing takes precedence over copyediting because it has a greater impact on the quality of theinformation from the users’ perspective.

Usability editingAs an advocate for the users, technical editors not onlyensure that the content is accurate and clear, but also thatthe content is usable. Spencer (1996) recommends an in-ternal usability review as a systematic way to identify basicusability problems. To the extent possible, technical editorstest the information and verify that the users will succeed.These “usability edits . . . give us a way of ensuring quality”(Soderston 1985, p. 17).

Technical editors cannot replace the usefulness ofactual usability testing; however, they can stand in forthe users by becoming the “first users” of the informa-tion. Technical editors use the table of contents andindex of the information deliverable to try to retrievevarious topics. They use the procedures and determinewhether the wording and formatting are easy to followand understand.

Editing has close ties to usability. Usability impliesworthwhile content, sensible organization, readablestyle, and effective design, all which are also primegoals of editors. Editors inherently judge logic andemphasis, root out redundancy and waste, and assessideas and their effects on costs and benefits. (Bush2001, p. 39)

When technical editors perform usability editing, theyengage in many types of quality assurance activities. Wewill focus on the following content editing activities thatare part of usability editing:

� Ensuring that the information can be retrieved easily� Making the information accessible to all users� Understanding the users well enough to make ap-

propriate decisions about style and content

Ensuring that the information can be retrieved easilyWriters often re-create text that already exists in a deliver-able because they themselves cannot find it. And if writerscannot find the information, how can users? Technicaleditors can ensure the information can be retrieved easilyby carefully reviewing the following:

� Table of contents Not all information deliverablesrequire a table of contents. Technical editors mustverify whether one is necessary. They also need todetermine whether it is complete or requires addi-tional topics or levels of topics.

� Index The index must be complete and mustcontain the appropriate entries, subentries, andsynonyms for the target audience. To check theindex, technical editors must try to locate the top-ics that they are editing within the informationdeliverable by looking in the index for appropri-ate and usable index entries. They also must re-view the index as a whole—as a separate deliver-able—to ensure that it is complete, accurate, andappropriate. “A thoughtful index increases thevalue of any book and helps guarantee that thebook will be used often because its content is ac-cessible” (Sencindiver 1991, p. 3).

� Topic titles Topic titles often are forgotten as anavigational feature, but they provide context for theinformation. For example, topic titles for Web pagesor for some online help systems are used in Favor-ites or Bookmark lists that users can build. Topictitles must be specific enough to show the contextand yet remain succinct. For example, “Features” ismuch too vague, whereas “Spell Checker Features”is much more descriptive.

� Metadata Metadata (or data that describes otherdata) consists of keywords that contain informationabout the topic. Sometimes the users can use thesekeywords within a Web site or online help system toretrieve information in a search request. However,these keywords also are used in a content manage-ment system to help writers find topics. Technicaleditors can build and maintain a list of approvedand appropriate keywords to use as metadata in ei-ther implementation.Testing these navigational features—using them just as

users would to follow instructions in the documentation orto find topics easily—is at the heart of most content usabil-ity testing.

Making the information accessible to all users Doc-umentation is accessible if it provides access to all usersregardless of abilities or disabilities. While the contentediting, usability editing, and copy editing help make theinformation accessible to most users, technical editorscan become advocates for disabled users and can helpmake the information accessible to all users. In the U.S.,

When technical editors performusability editing, they engage inmany types of quality assurance

activities.



section 508 of the Rehabilitation Act, amended by Con-gress in 1998 in the Workforce Investment Act, requiresas of 21 June 2001, that new software and softwaredocumentation sold to the Federal government mustmeet certain accessibility standards (U.S. Department ofDefense and others 2001).

For software documentation, this means providing alter-native text for graphics, figures, and tables; making helpavailable online in text format; documenting new ways toaccess the software such as command-line alternatives forgraphical user interface-based products, and so on. Addition-ally, technical editors can assist writers in running accessibilitychecking tools, such as the Bobby tool provided by the Centerfor Applied Special Technology (http://www.cast.org/bob-by/). Technical editors can advocate compliance with thesestandards and guidelines, along with all the other standardsand guidelines, and ensure that the information is provided inaccessible formats and structures.

Understanding the users well enough to make appro-priate decisions about style and content Users ex-pect information to be accurate, clear, and complete.Beyond expecting that the technical content will beunderstandable, users form perceptions about the infor-mation based on format, presentation, style, and evenchoice of words.

For example, users respond to words such as simplyand easily, as in “Simply configure the monitor’s x-axis.”These types of statements contain value judgments thatnot all users may agree with. Similarly, users may re-spond negatively to writing that is not gender-neutral.Because technical information is not a two-way conver-sation, the written information communicates to the us-ers through the “choices of words and graphics [that]have an absolute importance and finality” (Schriver1997, p. 183). Because graphics help communicatehighly technical information, technical editors must alsoreview the graphics and tables for quality, correctness,and effectiveness.

Finally, technical editors must apply guidelines forcontent and style within the context of the users’ needs,encouraging writers to “use language (both visual andverbal) that connects with the readers’ knowledge, experi-ence, beliefs, and values” (Schriver 1997, p. 166).

Copy editingAs an advocate for the language (and the users), technicaleditors review the information deliverable by deliverable,section by section, topic by topic, paragraph by paragraph,and line by line. Just as software testers perform functiontests and unit tests, technical editors methodically reviewevery word and every sentence. In addition to editing thecontent for accuracy, accessibility, usability, and clarity,

technical editors perform copy edits according to the com-pany style guide.

An editor, whose specialty is language and documentdesign, can suggest ways to make the document easierfor readers to understand and use. The editor knowshow to use style, organization, and visual design toachieve specific goals. (Rude 2002, p. 13)

When technical editors copy edit, they perform manytypes of quality assurance activities. We will focus on thefollowing content editing activities that are part of copyediting:

� Ensuring that the information can be easily under-stood (and can therefore be translated easily)

� Standardizing the information written by multiplewriters

� Verifying each information deliverable

Ensuring that the information can be easily under-stood (and can therefore be translated easily) Moreand more companies today are selling their software inter-nationally, expanding their customer base. Informationprovided with the product is often translated into multiplelanguages. The type of editing that improves the translat-ability of the information happens to improve the readabil-ity of that information for the native language, too. Theseediting techniques include the following.

� Use terminology consistently and carefullyAccording to Batty, “Effective communication inany context is made easier by the use of a com-mon language that both parties understand”(1998). Using standard terminology reduces thenumber of words that must be translated and en-sures that concepts are translated the same way ineach instance. Using the same word to representthe same concept throughout the information andnot using synonyms is preferred in technical writ-ing (a difference from our literary counterparts).Technical editors should maintain a master glos-sary to ensure the definitions of those conceptsare also the same throughout the information set.Controlling the writers’ vocabulary reduces thelanguage load and machine translation costs,while increasing the readability and usability ofthe information (Thrush 2001).

� Provide shorter, clearer text Translation height-ens the need for shorter, clearer text. Using fewerwords not only reduces translation costs but alsomakes it easier for users to find the needed con-tent (just as it does for users of non-translated in-formation). Technical editors help provide concisetext by eliminating redundancies, avoiding ambi-



guities, and paring the text to provide just enoughinformation (and no more) for the users to do thejob. It is important to provide solid content upfront so that fewer words need to be changed insubsequent releases, thus requiring less translationin the future.

� Improve the wording If the meaning of the textis clear in the source language, the translator isless likely to misinterpret the meaning. Addition-ally, automated translation software will morereadily be able to translate the text. Kohl (1999)recommends using a syntactic cues approach toimprove translatability. Syntactic cues are “ele-ments or aspects of language that help readerscorrectly analyze sentence structure [and] to iden-tify parts of speech” (p. 149). While copy editingthe information, technical editors can ensure thatthe information includes these syntactic cues toimprove the translatability of the information, in-cluding restoring the word that when it has beenomitted, ensuring one meaning per word, usingprepositions appropriately, creating parallel struc-tures, avoiding the use of metaphorical or culture-specific language, and retaining articles and prep-ositions where they aid comprehension.

� Provide cross-cultural examples During theearly drafts of an information development cycle,technical editors must work with writers to developand include cross-cultural examples. Weight loss andweight gain, dollar amounts, types of currency,icons, and graphics can have unknown or variedimplications for different cultures. Examples must bejudiciously chosen and implemented, and carefullyreviewed, so that the information is technically accu-rate and does not offend someone from anotherculture.

Standardizing the information written by multiplewriters Rarely is information for a software productwritten by a single writer. Soon—if not already—users,consultants, and other developers will contribute di-rectly to knowledge bases or knowledge managementsystems. Technical editors use templates, style sheets,prototypes, and company style guides to bring a consis-tent look-and-feel to the information. Using their languageskills, technical editors of multiwriter projects can make the

information seem as though only one writer has written theinformation.

Verifying each information deliverable Wheneverthere is time for proofreading, technical editors can en-sure the quality of every information deliverable. Astopics are combined to create an information deliver-able, and as information is presented in multiple media,technical editors need to verify that the total package isaccurate, usable, and readable. Verifying that the CDcontents, the PDF files, the index and table of contents ofan online help system, or the navigational links in a Website are the most current and accurate are all critical stepsin the process. Technical editors are responsible forperforming these final checks as quality assurance of theinformation deliverables.

TECHNICAL EDITING AS A VIABLE, SEPARATE FIELDDeveloping quality content for information deliverables isclearly a team effort. Although writing and editing aresimilar tasks, they are distinct and separate ones. As notedin the main premise of this article, software programmingand software testing are similar tasks, but they are alsodistinct and separate tasks. The value of team specializationis not always appreciated in the technical communicationfield, leaving information development teams to considerself-editing and peer reviewing as their technical editingfunctions. In describing the job of technical editors, Rude(2002) states,

Technical suggests not only the subject matter but alsothe method of working with the subject matter—to an-alyze, explain, interpret, inform, or instruct . . . . The artand skill of editing require specialized knowledge of theuse of language and methods of making sense of infor-mation. (p. 16)

The typical information development environment,much like the software development environment in whichit exists, is fast-paced and fraught with potential errors.Technical editors are the advocates and supporters of amore careful process to ensure that the users receive theinformation that they need. To that end, just as softwaretesting is a viable, separate field, so too should technicalediting be a viable, separate field.

Technical editing is differentfrom technical writingFor some technical communication teams, having a sepa-rate technical editor is an ideal arrangement, but one that isnot always achieved. As Taruts notes, “Many companiescombine the writing and editing functions into a singleposition, and many others don’t use editors at all” (1992, p.

Developing quality content forinformation deliverables is clearly a

team effort.



364). However, because technical editors interact with mul-tiple writers and most likely multiple projects, they have awider “perspective and are better able to find ways to savemoney and improve time-to-market . . . ” (Tarutz 1992, p.38).

Tarutz also observes that many people “don’t distin-guish between technical writing and technical editing”(1992, p. 13). To a degree, this lack of comprehensionflies in the face of reality because the skills associatedwith these tasks are not identical. The writer and theeditor do share skills—for example, “excellent writingskills” and “expertise in using publishing tools” (Tarutz1992, p. 14). Tarutz also points out that certain skills areusually specific to, or more developed in, each group.For example, the writer needs interviewing skills to re-trieve information from subject matter experts; the editormust pay attention to detail and still maintain the bigpicture (1992, p. 15).

Tarutz (1992) notes that editors “have always had ittough in industry. Editors are the last hired and the firstfired, under the justification that you can’t edit a manu-script that hasn’t been written” (p. 363). David Dayton(2002) has reported his research on online editing tech-niques (from a survey of STC members in the writer-editor category). He discovered that approximately 43%of the writers said that they were writer-editors, 34% ofthe writers said they were peer-editing writers, and only4% responded that they performed the traditional role oftechnical editors (p. 86). Dayton also reported that thesenumbers had declined from surveys he performed inprevious years.

Although this ratio of editors to writers may bedeclining, we do not believe that technical editing is afield facing extinction. In fact, the specialized skills thattechnical editors provide will become even more criticalas information is combined and recombined from a va-riety of sources into a variety of information deliver-ables. Technical editing will, of necessity, continue as aviable, separate field.

Considering self-edit and peer reviewTo save money, technical communication managers oftenrely on self-editing or peer reviewing, instead of having adedicated technical editor as part of the team.

According to Hackos, “Self-editing, a popular labelfor a lack of external editing, is both expensive andlikely to fail. Failures result because people run out oftime to edit their own work and lack the perspective todo so effectively” (1994, p. 361). Perspective is gainedwhen the writer can put the work aside and not go backto it for several days. And, this relates strongly to the timelimitation. Besides the lack of time and perspective, Hartidentifies a fundamental challenge when writers need to

edit their own materials or information written by col-leagues: “Editing and writing require entirely differentmindsets, and it’s difficult to make the mental shiftfrom creating to revising” (1998, p. 17). Writers are lesslikely to challenge the assumptions being made aboutusers because they already understand what has beenwritten.

Hackos (1994) writes that another failure of self-editing is that it is inadequate for ensuring product qual-ity. “When you have been working on a text for hours,days, or weeks, you are rarely able to find evidence ofinconsistencies, gaps, redundancies, or the other earlywarning signs of a ecline in quality” (p. 362). Technicaleditors “can bring objectivity to the [information] that thewriter may lose by knowing the subject too well” (Rude2002, p. 13).

Where self-editing fails, others try peer reviewing,which has its own set of advantages and disadvantages.“The advantage of peer reviewing is that all team mem-bers get to look at one another’s work. . . . They profitfrom observing other writers’ skillful approaches andsolutions to writing problems” (Hackos 1994, p. 367).However, to be successful, the peer reviewing processmust be worked into the information development pro-cesses and schedules, or “the system breaks down underthe strain of too much work and difficult deadlines”(Hackos 1994, p. 368).

Peer reviewers always put their own writing assign-ments before their peer reviewing responsibilities. Ac-cording to Tarutz (1992), “peer editors don’t approachthe task with the same attitude as a professional editor,”because it’s not their primary responsibility (p. 15). An-other disadvantage of peer reviewing is that “the qualityof the editing activities will vary dramatically” becauseeach writer will have different editing abilities, with littleclout to enforce standards (Hackos 1994, p. 368). Tarutz(1992) shares feedback she has received from writerswho have had their materials edited by both full-timeeditors and peer editors:

Writers who have worked with both professional editorsand peer editors have told me that [a technical editor’s]skills and abilities are what set apart professional edi-tors. (p. 15)

Where self-editing fails, others trypeer reviewing, which has its own

set of advantages anddisadvantages.



ADDING VALUE TO TECHNICAL CONTENTBush (2001) said it best: “Editing saves time, cost, and confu-sion. It’s magic” (p. 39). Perhaps it seems like magic because“good editing goes unnoticed by the reader” (Tarutz 1992, p.25). It is this sleight of hand—this magic—that technical edi-tors use to add value to the technical content—and to theproduct—throughout the product development process.

This article, which has compared the field of technicalediting to software testing, shows the great impact thattechnical editors can have on the quality of a product.“Information is good quality only when it contributes toimproved software usability” (Henry 1998, p. 215). Whenthe information has been through extensive technical ed-iting, just as the software has been through extensive test-ing, the users get quality information that supports a qualityproduct in the following ways:

� Users gain access to information that is clearer,more concise, and more comprehensible. The in-formation flows together well, unnecessary infor-mation is removed, and the sentences are clearand direct. Graphics, including lists and tables,help to present the information in a more conciseand visually organized manner.

� Less information increases the document’s usabilityand also produces savings in production and transla-tion costs.

� Users can retrieve the information easily from multi-ple navigational features (indexes and tables of con-tents) that have been tested and revised.

� The product information has fewer errors or areas ofconfusion for the typical users. This means that sup-port costs—such as staffing the help desk—are likelyto be reduced.As Henry (1998) notes,

Technical editing is a critical activity. It is not mere spellchecking or ‘correcting a document’ as some believe.Good technical editing contributes significantly to crit-ical design goals such as retrievability, readability, andclarity. Moreover, it brings consistency across all infor-mation elements. (p. 230)

As Tarutz (1992) reminds us,

It’s not enough to mark up a manuscript. If your editingdoesn’t produce improvements, if the writer ignores yourgreat suggestions, if your ideas don’t increase customersatisfaction—then you’ve just wasted your time. Allyou’ve done is a meaningless exercise of putting markson paper. (p. 366)

It is time for technical editors to answer this call toarms, to step up to being technical editors, or more impor-

tantly technical content editors, and to work within ourcompanies, projects, and environments to show that tech-nical editing is truly a quality assurance process. As cham-pions of our profession, we need to

educate writers, writing managers, engineers, engi-neering managers—and anybody else who influences[our jobs—about] the editing function. [We need] tobreak down that stereotypical image of the green-visored editor hunched over galleys to proofread formissed commas. Shatter this image by showing youcan contribute to customer satisfaction—through abetter product and better documentation. (Tarutz1992, p. 367)

Finally, just as software goes through a quality assur-ance process, with developers tracking and fixing defectsbefore the software is shipped to the customer, so must theproduct information go through similar quality assuranceprocesses, including technical editors editing the contentthough comprehensive editing, usability editing, and copyediting. For technical editors, the documentation is theproduct. Like software testers, technical editors add valueby ensuring that the product (the documentation) meetsthe users’ expectations and helps them easily use thesoftware. TC

ACKNOWLEDGMENTSSeveral people reviewed the manuscript and offered theircomments and feedback. The STC Carolina chapter’s Tech-nical Editing Special Interest Group (SIG) was extremelysupportive in kick-starting this article, listening to a presen-tation of its key concepts, and offering ideas. Anne Tice, themanager of that SIG, as well as John Kohl, of SAS Institute,reviewed the first draft of this article. We were also fortunateenough to have Judith Tarutz review the second draft of thisarticle. Their encouragement, editorial expertise, and detailedcontent editing comments improved its quality immensely. Finally,the Technical communication anonymous peer reviewers pro-vided outstanding detailed comments about our manuscript. Ourheartfelt thanks to all of them!

TRADEMARKSIBM and Tivoli are registered trademarks of IBM Corporation.

IEEE is a registered trademark of Institute of Electrical andElectronics Engineers.

REFERENCESAnderson, Steven L., Charles P. Campbell, Nancy Hindle,

Jonathan Price, and Randall Scasny. 1998. “Editing a Website: Extending the levels of edit.” IEEE transactions onprofessional communication 41, no. 1:47–57.



Batty, David. 1998. “WWW—Wealth, weariness, or waste:Controlled vocabulary and thesauri in support of onlineinformation access.” D-Lib magazine (November). http://www.dlib.org/dlib/november98/11batty.html

Bresko, Laura. 1991. “The need for technical communicatorson the software development team.” Technicalcommunication 38, no. 2:214–227.

Bush, Don. 1981. “Content editing, an opportunity forgrowth.” Technical communication 28, no. 4:15–18.

Bush, Don. 2000a. “A course in content editing.” Intercom47, no. 10:36–37.

Bush, Don. 2000b. “The other kind of editing.” Intercom 47,no. 6:40–41.

Bush, Don. 2000c. “Still another rule?” Intercom 47, no. 8:36–37.

Bush, Don. 2001. “Editing is magic.” Intercom 48, no. 6:39.

Bush, Donald W., and Charles P. Campbell. 1995. How toedit technical documents. Phoenix, AZ: The OryxPress.

Carroll, John M. 1990. The Nurnberg funnel: Designingminimalist instruction for practical computer skill.Cambridge, MA: MIT Press.

Carroll, John M., and Hans van der Meij. 1996. “Tenmisconceptions about minimalism.” IEEE transactions onprofessional communication 39, no 2:72–86.

Chillarege, Ram. 1999. Software testing best practices.Technical Report RC 21457. n.p.: Center for SoftwareEngineering, IBM® Research.

Dayton, David. 2002. “Electronic editing.” In Technicalediting, 3rd ed., by Carolyn Rude. New York, NY: PearsonEducation Group, pp. 84–105.

Grove, Laurel K. 1994. “When the basics aren’t enough:Finding a comprehensive editor.” IEEE transactions onprofessional communication 37, no. 3:171–174.

Hackos, JoAnn T. 1994. Managing your documentationprojects. New York, NY: John Wiley & Sons, Inc.

Hargis, Gretchen, Ann Kilty Hernandez, Polly Hughes, JimRomaker, Shannon Roulier, and Elizabeth Wilde. 1998.Developing quality technical information: A handbook for

writers and editors. Upper Saddle River, NJ: Prentice Hall,PTR.

Hart, Geoffrey J. S. 1998. “So you want to be an editor?”Intercom 45, no. 7:16–19.

Haugen, Diane. 1991. “Editors, rules, and revision research.”Technical communication 38, no. 1:57–64.

Henry, Pradeep. 1998. User-centered information design forimproved software usability. Boston, MA: Artech House,Inc.

Kit, Edward. 1995. Software testing in the real world:Improving the process. Harlow, UK: ACM Press, Addison-Wesley.

Kohl, John R. 1999. “Improving translatability and readabilitywith syntactic cues.” Technical communication 46, no. 2:149–166.

Mead, Jay. 1998. “Measuring the value added by technicaldocumentation: A review of research and practice.”Technical communication 45, no. 3:353–379.

Nadziejka, David. 1995. “Needed: A revision of the lowestlevel of editing.” Technical communication 42, no. 3:278–283.

Nadziejka, David. 1999. Council of Biology Editors guidelines,number 4: Levels of technical editing. Reston, VA: Councilof Biology Editors.

Prono, Judyth, Martha DeLaney, Robert Deupree, JeffreySkiby, and Brian Thompson. 1998. “Developing new levelsof edit.” Proceedings, 45th Annual Conference. Arlington,VA: Society for Technical Communication, pp. 436–440.

Rockley, Ann. 2001. “The impact of single sourcing andtechnology.” Technical communication 48, no 2:189–193.

Rosenquist, Deborah. 2001. “Information developmentorganizations evolving to keep pace with change: Acollaborative conversation of information developmentmanagers.” Technical communication 48, no. 2:194–199.

Rude, Carolyn D. 1987. “The rhetorical basis of substantiveediting.” Proceedings, 34th International TechnicalCommunication Conference. Washington, DC: Society forTechnical Communication, pp. RET 143–145.

Rude, Carolyn D. 2002. Technical editing. 3rd ed. New York,NY: Pearson Education Group.



Schriver, Karen A. 1997. Dynamics in document design. NewYork, NY: John Wiley & Sons, Inc.

Sencindiver, Martha. 1991. “Taking the mystery out ofindexing.” The editorial eye 14, no. 8:1–3.

Soderston, Candace. 1985. “The usability edit: A new level.”Technical communication 32, no. 1:16–18.

Spencer, SueAnn. 1996. “Use self-help to improvedocumentation usability.” Technical communication 43: no1:73–77.

Tarutz, Judith A. 1992. Technical editing: The practical guidefor editors and writers. Reading, MA: Addison-Wesley.

Thrush, Emily. 2001. “Plain English? A study of Plain Englishvocabulary and international audiences.” Technicalcommunication 48, no. 3:289–296.

U.S. Department of Defense, Government ServicesAdministration, and National Aeronautics and SpaceAdministration. 2001. “Federal acquisition regulation:Electronic and Information technology: Finalrule for implementing section 508 of theRehabilitation Act,” Federal register (25 April), RIN9000-AI69.

Van Buren, Robert, and Mary Fran Buehler. 1980. The levelsof edit. 2nd ed. Arlington, VA: Society for TechnicalCommunication.

Whittaker, James A. 2000. “What is software testing?And why is it so hard?” IEEE software (January/February):70–79.

ADDITIONAL READINGSBuehler, Mary Fran. 1980. “Situational editing: A rhetorical

approach for the technical editor.” Technicalcommunication 27, no. 3:18–22.

Buehler, Mary Fran. 1981. “Defining terms in technicalediting: The levels of edit as a model.” Technicalcommunication 28, no. 4:10–14.

Buehler, Mary Fran. 1984. “Rules that shape the technicalmessage: Fidelity, completeness, and conciseness.”Proceedings, 31st International Technical CommunicationConference. Washington, DC: Society for TechnicalCommunication, pp. WE 9–11.

Bush, Don. 1996. “The olden days.” Intercom 43, no. 9:37–38.

Bush, Don. 1999. “The Encouraging Prospect for Editors.”Intercom 46, no. 4:38–39.

Casey, Bernice E. 1981. “The impact of the technicalcommunicator in software requirements.” Journalof technical writing and communication 11, no. 4:361–372.

Conklin, James. 1993. “The next step: An integratedapproach to computer documentation.” Technicalcommunication 40, no. 1:89–96.

Gerich, Carol. 1994. “How technical editors enrich the revisionprocess.” Technical communication 41, no. 1:59–70.

Killingsworth, M. Jimmie, and Betsy G. Jones. 1989.“Division of labor or integrated teams: A crux in themanagement of technical communication.” Technicalcommunication 36, no. 3:210–221.

Potsus, Whitney Beth. 2001. “Is your documentationtranslation-ready?” Intercom 48, no. 5:12–17.

Putnam, Constance E. 1985. “Myths about editing.”Technical communication 32, no. 2:17–20.

Scholz, Jan. 1994. “Developing technical documentationthe smart way.” Technical communication 41, no.4:94 –99.

Shirk, Henrietta. 1988. “Technical writing’s roots in computerscience: The evolution from technician to technical writer.”Journal of technical writing and communication 18, no 4:305–323.

Zuchero, John. 1995. “Using inspections to improve thequality of product documentation and code.” Technicalcommunication 42, no. 3:426–435.

MICHELLE CORBIN is a senior technical editor at IBM®working on Tivoli® software. She has 12 years experience asa technical writer and technical editor, focusing much of herenergies on the design and implementation of online infor-mation systems. She has a BA in English and an MS in Tech-nical Communication, both from North Carolina State Univer-sity. She’s a senior member of STC and a past president ofthe Carolina chapter. Contact information:[email protected]

PAT MOELL is a manager of the technical editing depart-ment at SAS Institute Inc. in Cary, NC. She has a BS in En-glish and mathematics education from SUNY Plattsburgh andan MLS from the University at Albany (SUNY). She has also



completed course work for a doctorate in InformationStudies from Syracuse University. She is a senior member ofSTC and has received a Distinguished Chapter ServiceAward from the Carolina chapter for her contributions tochapter leadership and for helping to establish the chapter’sTechnical Editing SIG. Contact information: [email protected]

MIKE BOYD is a self-employed editor and instructional de-signer in Cary, NC. He has a BS in radio and television fromIndiana University, Bloomington, and an MA in educationaltechnology from the University of Iowa, Iowa City. He is a se-nior member of STC. In addition to his editing and instructionaldesign experience, he has worked as a technical writer. Contactinformation: [email protected]



technical editing as qa

Documents