I love the flexibility of web publishing. The process 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.

My contractors and I have been proofreading a quarterly digital magazine since its inception several years ago. Starting with this year’s second-quarter issue, the magazine was no longer going to be published in the magazine app; instead, it would be published as 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 has 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 was not 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. Predictably, 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. Finally, design problems continued to go into 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 quality control was at risk. We had done as we had 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 my obstacles with it 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 work 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 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. And next quarter, this problem should go away.

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

• 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.
• 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 mean 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.