Skip to Content

The Value of Communicating and Coordinating in Proofreading

Ariel view of a team of business people around a meeting table.

I love the flexibility of web publishing. It’s a process that can be adapted to individual situations, enabling time-crunched projects to publish on time.

But that same flexibility can lead to disaster without proper team communication and coordination.

One project my contractors and I had been proofreading was a quarterly digital magazine. A few years into working on the project, the client decided to stop publishing the content as a magazine; instead, they would publish individual articles on a website.

This was a massive change. It involved bringing in a blog design-and-publishing team, in addition to the usual design and editing teams. Plus, the publication had many stakeholders, which often leads to conflicting requests and delays.

As with any big change, the project took longer than estimated. Since the front half of the process was unchanged, copy was approved and ready to flow into design on schedule, but the webpage design wasn’t yet completed.

This is where the flexibility of web publishing comes in: The design team was able to flow the copy into the content management system (CMS) and my team was able to proofread the text. Design elements and interactive elements would come later.

After that, the process started to break down.

My team was asked to proof article pages in PDF files. Anticipating few corrections, design asked us to list corrections in a spreadsheet. Unfortunately, there were more corrections than were practical to list in a spreadsheet. We were then asked to mark up the PDFs instead—a process we’d done in the past.

Here too, though, we ran into problems. The PDF was saved as one image, resulting in small type, unopened interactive boxes, and unclickable links. We had to go to the online preview webpage to check links and proof copy in the interactive boxes, only to add those corrections to the PDF. We also were limited in our use of markup tools; highlighting, for example, was unavailable. And design problems were to continue to be listed on the spreadsheet.

We soon became frustrated. There were too many places to check and too many places to enter corrections. The work was taking too long, and content quality was at risk. We had done as we’d been asked, but it seemed to be the wrong solution.

So I did something editors and proofreaders (myself included) are often reluctant to do: I asked why we were working this way. I pointed out the obstacles we’d been facing and my concerns—but without assigning blame. My main message was: Can you help me understand why we’re proofreading this way?

I have to say, we worked with a good team on this project. The explanation came back quickly and was enlightening: The blog design team was still working on a page template for the articles and it was unstable, particularly when more than one person was working in the article page in the CMS.

The reasoning made sense. I asked for the image to be created with all boxes open, limiting how much we had to check in the preview page. We also cross-referenced corrections between the spreadsheet and the PDF file and made extra efforts to ask questions and communicate issues in team emails.

We made it to publication on time through extra work on the part of both the editing and design teams; the client was happy. 

The situation, though, offers two great lessons for proofreaders:

  • Communicate. When you don’t understand what’s going on, ask questions. Share your needs and describe how the process is affected. Seek to understand your colleagues’ needs as well. Staying silent will only increase your frustration.
  • Coordinate. As proofreader, you’re working as part of a team. Consider what’s best for the project as a whole and work with your colleagues to get the work done. Sometimes this will require extra effort on your part, sometimes on someone else’s.

We editors and proofreaders tend to work in silos—just ourselves and the words. Once in a while, though, we have to emerge from the silo to work with teammates. Putting project needs first will lead to a better finished product.

This article originally published on 07/07/18 on


Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.