My Top Three Editor Roles

By Sherri Leah Henkin | STC Senior Member

In 2016, the STC Technical Editing SIG held a Watercooler Chat entitled, “Technical Editors Wear Many Hats.” We discussed the evolving role of an editor and various roles technical editors play. Some common responsibilities emerged:

  • proofreader
  • trainer
  • peer reviewer
  • writer
  • video creator

Not all editors wear these specific hats. I have some days where I focus on proofreading, for example. Generally, though, I juggle several editor roles during a given day. Here are my three favorites.

1. Peer Reviewer
What It Is

Peer reviews aren’t formal editing. My colleague wants another professional writer to provide objective feedback that improves the piece. Sometimes, it’s an early draft and my colleague wants another read to help her organize the piece. Other times, a fellow writer emails the story to me for one last review to make sure the piece flows. I critique stories, blog posts, articles, chapters, or online course material.

How I Do It

Colleagues ask if I have time to review their piece. I receive the document in Word or PDF. Since this is review, not a copyedit, I provide feedback in comments within the document. My review focuses on readability, format, and suggestions to correct minor grammar/punctuation issues.

There’s a side benefit to these reviews: I read material before it’s published!

Examples from the Trenches

Case 1: Tightening Up a Blog Post

I reviewed a short article about a personal medical experience that a colleague wrote for a nonprofit organization. The organization planned to publish the article on their website. I suggested removing details that detracted from the main point. I also guided the writer to switch from passive to active voice.

Case 2: Consistent Fonts and Format

A colleague sent me a chapter of a workbook in PDF. She had used five different fonts, multiple graphics, and several bullet point formats. The writer asked me to look at the format and activity instructions. I provided guidance about breaking out instructions into additional steps and ideas to clarify vague terms. I suggested that she select a maximum of two or three fonts, and standardize the bullet formats. Some of the graphics detracted from the instructions, and I suggested she remove those graphics.

Case 3: Compelling Cover Letter

Occasionally, a friend asks me to review a cover letter for a job application. I consider these peer review activities because the writer wants objective input to improve their letter. Recently, I reviewed a cover letter for a teaching position in adult education. The letter writer had the qualifications; the issue was formatting. I suggested she use headers, bulleted lists, and quote text from the job posting. My goal was to help her improve the readability and easily highlight how she matched the requirements. (She got the job!)

2. Proofreader
What It Is

Unlike peer reviews, as a proofreader, I’m brought into the project in its final stages. Proofreading goes beyond the spelling/grammar check tools. The manual proofreader catches errors that a tool may have missed. My goal is “to eliminate grammar problems, typos, spelling errors, and usage mistakes” (Johnson-Sheehan, 8). I may also check for factual errors and inconsistencies.

How I Do It

A client sends me a draft article in Word or PDF, or the website link. Occasionally, the client requests specific sections for me to proof or recurring errors they suspect are in the document. While I enter the edits into the document, I also keep a list of the recurring errors I find and provide that list in the cover email.

I use a style guide for reference. If the client has a preference, and/or a company guide, I use that. Otherwise, I’m a Chicago Manual of Style aficionado!

Examples from the Trenches

Case 1: Newly Launched Website

The task was to proof the client’s initial blog posts; the client sent me the link to the live website. One post had this bold headline: Heart Attach [sic]. I quickly emailed a screenshot to the client before adding this error to my list. “Yikes! I proofread that title many times!” my client stated in her reply email. “It’s supposed to say, ‘Heart Attack.’” “Attach” is a good word but not the right word for this context. The client edited the headline while I continued to proof the other posts.

Case 2: Newsletter

While much of the information in this community hard-copy newsletter was culled from existing sources, with permission, this client needed proofreading before the newsletter went to print. I standardized the format. To check the facts in the source material, I researched some of the historical data and publication information. One story stated that an event happened in 2018; the event had occurred in 2008.

I had an additional language challenge with this project: Hebrew terms transliterated in English. The spelling of the transliterations was not consistent. I found recognized sources for spelling transliterations and edited terms.

3. UX (User Experience) Editor
What It Is

I originally hadn’t thought of UX testing as editing. And maybe technically it’s not. I consider it editing because I want to suggest a term or process that users are familiar with, making the user experience pleasant.

How I Do It

My client sends a link to either a live site or one ready for beta testing. Typically, the client outlines specific sections for me to test. I provide suggestions for edits/corrections/improvements from the consumer point of view. I don’t address changes in the coding; I leave those changes to the developers.

Examples from the Trenches

Case 1: Missing Log-in/Log-out Buttons or Instructions

An educational institution asked me to log in, check the navigation links, and log out on a secure section of their website. After I clicked on the website link, I figured there would be a log-in button. I couldn’t find it, or a link, or instructions to log in. I emailed Tech Support. Tech Support’s response: “We don’t have a log-in button. Here are the steps to log in to the website.”

After logging in, navigating the website went smoothly … until I wanted to log out. There was no log-out icon or link. I figured maybe just closing the browser would automatically log me out. When I reopened the browser, I was still logged in. Back to Tech Support. “Where’s the log-out icon?” I received this email: “Oh, we don’t have one. I need to send you a special log-out link.”

My feedback to the institution? It was difficult to log in and log out. Not being able to logout is a potential threat to the user’s privacy and security. Add simple log-in/log-out buttons or icons. Tech Support appreciated my feedback:

Your feedback means so much. I have been working to get a button on the page for over a year, just so people know when they’re logged in. My next step is to add a way for people to log out—I will be using your feedback to advocate for a log-out button. I completely agree, it’s another step to ensure privacy and protection.

Case 2: Donating on an Unsecured Website

A nonprofit organization requested that I navigate through their site and try some features. We agreed that I would try and donate to test the automated responses and website security.

On the main page, there was no Donate icon. Why make a potential donor hunt through the site to give money? When I did find the donation page, I noticed that the website address wasn’t secure.

My suggested changes? Secure the donation page. Consumers don’t want to provide PII (Personally Identifiable Information) on an unsecured website. To make it easy to donate, add Donate icons on all pages.

Case 3: Live Website Passes UX Test But Fails Grammar and Spelling

Testing this live website went well; navigation was smooth and easy. The client asked me to give a cursory review to some of the text. However, in my cursory review of text, I noticed possessives when the word should have been in plural form and misspelled words.

I notified the client, and we agreed that I would read the text carefully. While this was initially user testing, we combined proofreading. After all, if the text has typos and grammar mistakes, that contributes to an unpleasant user experience and potential loss of business.

Editors wear many hats. The commonality is attention to detail. And I enjoy that! To paraphrase another proofreader colleague, I get to be the last eyes on the content. It’s rewarding to help colleagues and clients produce readable, error-free content!

Note: This article expands the STC Technical Editing SIG’s Corrigo article posted in April 2017.


Johnson-Sheehan, Richard. Technical Communication Today. 5th ed. New York: Pearson, 2014.

SHERRI LEAH HENKIN is a Senior Member of STC and active in the Technical Editing SIG. Sherri has published tech comm-related articles in Intercom, Corrigo, and chapter newsletters. In addition to tech writing and editing, Sherri writes and publishes creative non-fiction. Contact Sherri through her website, www.contentclarified.com.

Download the Apr 2017 PDF

2017 PDF Downloads