Six lessons from dysfunctional projects
There are no rules for designing a publishing workflow. If machines run, humans are creative, and high-quality products emerge on time, then you’re onto a good thing. Still, even with good systems in place, things go awry. Why?
After decades running hundreds of publishing projects, we use these six simple questions to diagnose workflow problems. They apply to single publications as well as entire publishing programmes.
1. Is there one leader and champion?
Every publication must have one leader and champion. I’ve written about the importance of this for CORE’s acclaimed textbooks. In traditional publishing companies, this role belongs to the publisher or commissioning editor.
The leader–champion cares more than anyone about the success of the publication, and they have the authority to make decisions about it at every level. They read everything that goes into it, review every design, and understand how it fits into a broader strategy – while trusting each member of the team to bring their best work. This is critical for coherent, effective, efficient publishing.
When ultimate accountability is unclear or distributed, a project loses momentum and corners get cut. This often happens when a senior executive initiates a project and then steps back to let their staff run it. It’s extremely unlikely that someone else can step into a role that requires strategic decision-making and a strong sense of ownership.
The leader–champion should not be the author, though a co-author can work out okay. When the project’s leader is also the only author, their ego can make it hard for everyone to put the project before the person. This is a common dilemma in self-publishing.
2. Is there a single source of truth?
Every part of a publication – every text file and every image – must have a single source of truth: a master version. This is a publication’s most up-to-date, official, editable collection of files. Everyone on the team must know exactly where the master is. There must not be any doubt in anyone’s mind about what specific files constitute the master version, and how to access and edit them. And everyone should understand that any other version is instantly, inherently out of date.
For example, imagine that your book was written in Word, typeset in InDesign, and output to PDF. Where is the master version? The master is the original InDesign file, since that is the last, editable version. Now, is it on the typesetter’s machine, or in a shared Dropbox folder? If another typesetter works on it, where is the master then? Does everyone on the team know at all times? They should.
A surprisingly common problem is that authors update published books by editing old Word files, forgetting that the master has long diverged. If they understand that a master version exists, and is always evolving, they will be more careful to update the correct version.
Any confusion about what constitutes the master version is a red flag. We call this a multiple-master problem. When a publication has multiple masters, confusion and delay becomes inevitable.
3. Is there a reliable system for version control?
Can you trust that the master files match the latest version of the publication? For instance, if Alice changed the figure numbering yesterday and sent you a new PDF, did she change the figure numbering in the master, or only in her copy? Can you find out from your version-control system? Let’s say she did. If you decide against her new numbering system, can you roll back to a previous version instantly?
And, months later, can you look back through versions to see when and why figure numbers were changed, and who changed them?
We’re often looking back through our version-control system to understand why and when decisions were made. This is especially common on big, complex projects with lots of contributors. We developed our own content management system to let non-technical team members use Git version control without technical knowledge.
It’s also possible to use Google Docs’ version history for this, if used deliberately (with named versions) and managed well.
4. Is content separated from design?
Perhaps the main aim of any modern workflow is to separate content from design. This means that you maintain the content in one place, and can flow it into any number of formats and designs. The designs for each format are stored in separate stylesheets or style libraries.
True content–design separation is best handled in a digital-first workflow. Still, even in InDesign it’s technically possible, although precious few designers and typesetters use these capabilities. If you’re using InDesign’s story view often; maintain thorough, documented style libraries; and never use local overrides, you’re doing this well. You can then easily copy text from one InDesign document and flow it instantly into a new design for a completely different product.
In our workflow, we store content in plain-text markdown, and create separate CSS stylesheets that define page layouts and web and ebook designs. We can quickly build complex stylesheets from a library of base styles.
When content and design get mixed up in the same document, they can’t be easily reused; you can’t have different people working on editorial and design issues at the same time; and good version control is hard to achieve.
5. Can everyone on the team open the files?
Given some basic know-how, can every member of your team access and work on the publication? If not, problems arise.
First, your workflow has key-person risk. If one or two people are away, changes can be hard to make, or can be delayed. Skills don’t get transferred, and silos develop as people become territorial about their particular role. Team members become frustrated by having to delegate every change to someone else. Misunderstandings lead to lengthy to-and-fros as PDFs fly back and forth. You end up with inefficiency and bad team dynamics.
InDesign-based workflows suffer especially from this: you have to pay a lot for InDesign and have a powerful computer to open and edit the files.
Modern workflows, whether web-based or not, allow for multiple contributors at low cost. This level of access is fundamental to efficient publishing.
6. Can you effortlessly export a finished publication?
In every workflow, finished publications are exported from master files. In traditional publishing, we have the ‘Export to PDF’ command in InDesign. In modern workflows, you might run a ‘Generate epub’ script or click ‘Build website’.
Sometimes you have to go through several manual steps to export a finished publication. For example, to generate a Windows app for some of our projects, we have to run a script and then complete a few steps in Visual Studio to build and certify the app. This can take several minutes.
Here’s the key: exporting a new file must take less human interaction than it would take to edit a previously exported version. This is surprisingly tricky to achieve.
A few years ago, converting an InDesign project to an epub took several hours. We’d do the conversion once and then, when changes came in, edit the epub separately from the InDesign file, resulting in multiple masters. This doubled our work and was prone to human error. We eventually dropped InDesign for a digital-first workflow that took twenty minutes of interaction to produce a finished epub file. This was still too long. If we had to make a small correction to the text, it was too tempting to make that change to an existing epub file, rather than updating the master files and generating a new epub.
Only a couple of years ago did we get epub-export to under a minute of human interaction. (Depending on the complexity of the book, a computer might still need several minutes to generate the file in the background, leaving humans to get on with creative work.)
Our rule of thumb is that if it takes more than five minutes of human interaction to export a fresh publication, then multiple-master problems will arise.
Sharing best practice
If you’d like to learn more about our workflows or tell us about yours, we’d love to talk. We’re as keen to learn from your experience as we are to share ours.