Looking to get more out of InCopy? Consider Adding Write-first to Your Workflow
One of the things that makes InCopy such a powerful tool for publishing workflows, is the numerous ways in which it can be implemented. Although there are some common workflow configurations that are widely used in the industry, I have to say that no two InCopy configurations are exactly the same. The reason for this is simply because no two companies are the same.
One of the most common InDesign/InCopy workflows begins in Adobe Indesign where the designer lays out the document and then makes content available to InCopy users by exporting InCopy stories so that the layout or assignment can then be edited using Adobe InCopy. There’s a reason why this workflow is so widely used. Because it works! There are limitations though. In many organizations, there’s often a lull from the time copy is sent to design until it is made available to them for edit in InCopy. If changes need to be made to the copy, editorial staff has to wait until the content is made available. In addition, formatting the copy can be time consuming for the designer and if care is not taken, there’s the potential to lose critical formatting such as bold and italics during the layout process.
Introducing Write-First
A variant of the InCopy workflow is what I refer to as the write-first workflow. In this situation, editorial staff actually write content in Adobe InCopy. With a well designed InCopy template, this provides editorial staff with styles that they need to apply basic formatting to content such as headings, subheads, body, bold, and italic. There are numerous benefits to this approach:
- Writers and Editors can now visually see the content how it’s actually going to appear in the final product including proper vertical spacing between elements.
- By using bold, italic, and bold italic character styles, formatting is retained throughout the entire workflow.
- Because InCopy and InDesign share the exact same type engine, formatting is retained when InCopy stories are placed in an InDesign layout.
What about Microsoft Word?
This workflow isn’t necessarily a replacement for Microsoft Word. Many times it’s a complement to the traditional Word to InDesign workflow. For example, it may still be necessary to pass the Word document back and forth between the author and the editor until the article or content is finalized. This is very normal. After the content is finalized however, you may decide that it makes sense for someone on the editorial side to flow the Word document into InCopy, apply some basic formatting, and then pass the InCopy stories onto design.
I’m an Editor, not a Designer
I hear this one all too often when I talk about this type of workflow. The goal of the write-first implementation is not to make designers out of editors. It couldn’t be farther from the truth. The reality is that the editorial staff needs to in some way indicate the role of different text elements such as headings, subheads, captions, bold, italic, etc. Traditionally I’ve often see users put brackets or some other indicator in the text to indicate that <<this is a heading>> or <<make this a caption>>. Although this method works, in the end, the designer has to spend time to remove that additional text from the final version. By using styles, you’re indicating the role of text elements with the click of a button and formatting simply becomes a side-benefit of that process.
Wrapping Up
The idea behind adding write-first to your workflow, is to provide options. As staffing changes occur, you could end up heavy on the editorial side where write-first could help to streamline the workflow in your organization. Write-first could also minimize downtime by allocating more time to the editing process so they aren’t waiting while text is formatting by the designer during layout. Regardless of the reason, think about how implementing write-first in your organization could optimize your workflow.
![]() |
This is tangential to the author’s main point, but it does involve InCopy, which I have been using since it was first introduced.
This applies to my own work. I no longer use Word for any text that I am going to import into InDesign. I start with InCopy. I consider it my Word.
A couple of years ago I saw an ad for a copy editor at a newspaper in Pennsylvania. The editor was required to know InDesign and InCopy. I asked and learned that reporters composed their stories in InCopy. Makes sense to me.
Actually, not tangential at all Thomas. You’re workflow is a prime example of the write-first workflow although it sounds like you dove in head first which is great. Not all companies can do this because if you’re working with external authors it can be difficult. Thanks for the great testimonial that this workflow works!
I’m in the middle of switching to an InCopy workflow at the publishing company where I’m production manager. Since the editors are very familiar with Word, my method is to go in stages. Stage 1 the editors create the rough copy in Word and combine it into final documents using Word macros they are familiar with (in our workflow, a lot of little pieces written by various editor are combined into final articles). I’m also creating scripts for the editors that automate importing the Word docs, preparing the text, applying character styles instead of formatting, and anchoring graphics frames in the story for repeating elements. Proofreading and final editing will happen in InCopy. After we switch, when everyone is fully trained, we’ll remove Word entirely. The planning is taking longer than the training probably will!
When to remove Word is always a delicate balance and one that each group tackles differently. Chad’s dead-on that every workflow is different. This is why its important to make sure your tools can adapt to the way your team is most efficient and not the way the software developer thinks you should work. This is one of the things we always preach when we’re working with a customer to rethink their workflow.
Of course, no workflow works 100% of the time so its important to remember that even when you use an write-first InCopy workflow, there will be times that you need to stay in Word till the very end or go back to Word for a revision by a non-InCopy user after working in InCopy.
And as much as we like to avoid it, there is going to be those times where you need to use PDF, or even good old paper. The goal is to make that the exception rather than the norm.
Hi Chad, I’m a designer that works with a group of writers for a publication. We use the write-first method and the writers format their copy using paragraph styles. Although things work well, I’m interested in learning more about how other companies’ are using InCopy in hopes of improving our current workflow. Any advice you can offer would be greatly appreciated! Thanks, Michele
Where can I find steps to implement a write-first workflow? I need to train editors and designers.
Hi Vatrice,
I talk a little more about the write first workflow in my Lynda.com course that you can access here https://www.lynda.com/InCopy-tutorials/Learning-InCopy/521143-2.html. Beyond that, you can contact me directly at [email protected].
Hi Chad, you mentioned it is difficult to use InCopy or the write-first workflow when dealing with external editor. Actually sometimes we deal with this point in my work and we depend on word documents all the time before using indesign. The external editor emails his word document that is also have images inside to be used or as a guide for designers. But the document should come through some stages of amending by another editor and revising by another language proofreader until coming to the designer. So designer will wait a lot until he receive the document to work on even if he already designed the layout and icons of the book. So would you explain how exactly InCopy will be of good help and what the detailed steps to follow even if we had to change the process to work on InCopy as well. Is there a way to make designers work and not wait for these stages of word writing and amending. Also the designer takes time to finish his design and export it to pdf that has to be revised again by the author who put some notes and final amending when he see the PDF copy.
You have several options Ahmed. First of all, if there is a lot of back and forth between author and editor in the beginning, then it makes sense to stay in Word. As the designer, I’d use that initial Word doc to create a framework for the page ahead of time to get a jump start on the design. From there I’d suggest having an editor flow the Word document into InCopy and provide that to the designer. That way if any changes need to be made, it can be done in InCopy and the updates can be in turn updated in the InDesign layout. The amendments from the PDF will need to be done by somebody using InDesign or InCopy.
As I’ve said many times before, sometimes it’s your workflow that needs to be evaluated. It sounds to me looking at this at a high level, that you’re trying to shoe horn the tool to the workflow which can work, however I’d start be evaluating the workflow and deciding if changes need to be made to make the process more fluid.
We have been using InCopy, where I work, for almost a year now. It has sped up production and shifted the “work load” more evenly. But, we experience lots of crashes, files freezing, corrupt files and loss of content, while using InCopy. We have been able to troubleshoot some of the causes, for example, anchored objects cause corrupt files.
Are others experiencing this? I wonder if this is the norm or we are doing something incorrectly when setting up files or something. It can be very frustrating.
Nicole – we have experienced similar issues with InCopy in terms of server slowdown (too many people working off the server at once?), files freezing and loss of content. We have been troubleshooting with our IT team and cannot figure out the issues outside of it being server related, although we have added memory and cleared a lot of space. If anyone has any ideas, would love to hear them! It’s been frustrating and a barrier to full implementation.