Make the pieces benefit the whole.

Originally published on Digital Book World’s blog.

In the Production, Distribution and Operations track I programmed at Digital Book World last week, it struck me how much challenges with publishing workflow architecture echoed across virtually all of the sessions. Especially striking was how we are looking at workflow in a new way these days: holistically, across the whole process of authoring, acquiring, developing, producing and delivering content in our multiformat, multichannel world.

Workflow is often developed very narrowly, and I’m not implying that’s inappropriate in many cases. I counsel my consulting clients to approach technology development in an agile, modular way: trying to create one big end-to-end system is almost always futile. Optimize the process of copyediting for the copyeditors, using tools they use naturally. Optimize the typesetting process for the types of content you’re publishing. Optimize digital products for the ways in which end users will best consume them. Apex recently published an Executive Guide exploring these issues and strategies.

But another absolutely essential piece of advice when developing and refining a publishing workflow architecture is to avoid suboptimization. It’s all too easy, in optimizing things for the folks at one stage of the workflow, to accidentally make things harder for folks at other stages. Instead, you need to broaden your field of vision and ask:

How can this part of the process best benefit the process as a whole? How can we make it easy for the people doing this part to make it easier for others as a natural byproduct of their work?

Let me give you some examples.

At the very beginning of the process—authoring, and the acquisition of the authored content—the prevailing assumption is that trying to get authors to do what you need them to do is impossible; you just have to deal with their messy Word files and their unusable artwork. Well, yes and no. It’s true that it’s almost always futile to make authors create Word files the way you need them to be. But that doesn’t mean the editing and production folks who have to work with them have to suffer.

The most successful strategy—one we live by at Apex and that I was pleased to hear so many of the DBW speakers echo—is to get those files in a consistent, richly structured form right away. In some cases, that means going straight to XML or HTML; the latter is the secret to Hachette’s brilliant process, which Dave Cramer so effectively showed at DBW. More common is to get those manuscripts into a well-designed Word format that uses styles to distinguish all the components. That makes it way easier on the editors, project managers, copyeditors and compositors who have to work with them.

This can even work with images. Apex has a tool called PACE that automatically assesses artwork uploaded by authors, reports issues that need to be fixed, automatically fixes some of them (for example, converting to the proper file format), and makes it easy for a non-technical person to fix the others. When we’ve implemented this for publishers, they’ve found that, far from resisting it, authors love it—and they actually use it, believe it or not. Anybody familiar with how snarled up a workflow can get from unresolved art issues will appreciate how much cost, delay and friction this eliminates. Making this easy for the authors makes things easier for everybody else in the workflow.

Now let’s look at production. Even if you don’t go straight to XML from those messy Word files you get from authors, that well-designed Word format should be designed to automatically generate the XML you need, as soon as copyediting is complete. Does this mean you need a high-end composition system like 3B2 to do the typesetting? Well, for publications that are consistently formatted, sure, that’s absolutely the most efficient. But even for publications that need to be individually designed and typeset using InDesign, this same strategy works.

I do not recommend using IDML, the XML format of the InDesign files themselves, because that is too presentation-oriented and can lose structural information that’s essential for digital products and accessibility. Instead, your XML can be optimized so that it is imported directly into an InDesign file, where it is automatically associated with InDesign styles controlled by the designer and typesetter. The publications can all have individual designs and layouts, but under the hood they retain a consistent structure, encoded as XML, that enables you to generate the files needed for EPUBs and online presentations automatically.

There goes a whole lot more friction—and cost and delay.

This sounds hard, but if done well, it isn’t. What we’ve found in practice is that designers and typesetters love it. Why? Because it enables them to work the way they want to work, while providing them source files in a form that is predictable and optimized for how they work. Everybody wins.

The message here is this: design the bits and pieces of your workflow with the whole process in mind. Make sure that when you’re improving one component, the results benefit the process as a whole. This simple and seemingly obvious strategy is too often overlooked.

I mentioned Apex’s recent Executive Guide with more information. It would be a good place to start. You can download it for free here.