Why Technical Publishing Shouldn’t Be Art
by Alan J. Porter
“Writing is a solitary occupation. Publication is a group exercise,” so stated novelist Madeline Robbins. And she’s correct. The work may start with the author, but to get it from the author to the end reader means it also has to go through an editor, copy editor, book designer, typesetter, printer, sales and marketing team, distributor, book buyer, and, eventually, a retail store. It’s a model that the book market developed centuries ago and still works today. Although it could be argued that the Web and print-on-demand are altering the delivery mechanisms slightly, the same basic process still applies. The book trade is based on the fact that the artistic elements, the creation of the content, and the design of the book are small parts of the overall process, and that the publishing process is a business that only flourishes through being scalable and repeatable. Yet the more I write books and the more I become involved in the book business the more I am struck by the differences between it and what has been my “day job” for over twenty years, technical publications. Over the years, I’ve been trained and worked as a writer, editor, document designer, coder, formatting expert, content management specialist, and workflow designer. I’ve used software tools that applied to every one of those disciplines. And here’s the point: often at the same time. As I talk to people in the tech pubs industry today, I still find that in most cases it’s the same person who writes the content, designs the documents, and uses special tools to publish the material — be it for Web, online help, or print (again, often managing multiple deliverables simultaneously). Not only is one person doing the whole job, but often several people are all doing the same thing in parallel. (See Fig. 1.) In other words, instead of several people contributing to an overall process, we have individuals each creating individual results. It could be argued that with this individualistic approach, what they are delivering isn’t a complete product but instead individual pieces of “art.” The problem with art is that the results vary. Give a canvas and a box of watercolors to a landscape painter and a second-grader. The same materials, the same process, but you get very different results. Install an editing tool, a help design tool, and a deployment tool on two computers. Give them to two equally experienced technical authors — one who is great at writing content and one who is passionate about typography and usability design. Same tools, same process. Again, two completely different results. The problem inherent in the artistic approach of having every technical author have full access to every tool in the production process is that it isn’t only the best who impact the quality of what you deliver, it’s also the worst. Natural tendencies toward areas of greatest comfort and skill also permeate. When I ran a large technical publications shop, I could open any document at random and tell from the page layout and language who produced that particular book, even though they all complied with both corporate and industry standards. The “author as artist” paradigm increases training costs, as every person has to become knowledgeable about every tool used in the process. Cost of ownership of those tools also becomes high as in a multi-author environment any updates to tools or changes to style templates, business process models, new standards, etc., have to be simultaneously propagated across all machines, and everyone must be retrained. Such parallel production also makes it difficult to measure progress and quality and tends to focus time and resources on getting consistent results. So why not borrow from an allied profession that has been using a well-developed system for a couple hundred years? If we design the process rather than the result, it can reap dividends in quality, proficiency, speed, and overall costs. By separating each of the processes into separate stages, each handled by a specialist with the applicable tools, just like the book industry, we can streamline and even automate the business of technical publishing. In fact, thinking of what we do as a “business” rather than just a necessary “overhead” will go a long way toward not only improving the way we do things, but also help tech pubs gain recognition in the corporate structure (but that’s probably fodder for a future column). So let’s take a look at how we can transform our group of artistic “technical authors” into a more efficient “publishing business.” Everyone on staff is different. They have different skills and interests. Find out what those skills and interests are and focus them in that area.
- Have a couple of great content developers who have a real knack for talking to SMEs and translating geek speak into easy-to-follow user instructions? Focus them on content development and the use of your preferred editing tool.
- Got someone who is passionate about page layout and typography? Have them design the WYSIWYG templates for the editing environment.
- Got someone who loves to get into the taxonomy of what you produce? They could be a great information architect, and if you are going to a structured environment like XML or DITA, have them design and maintain your schemas and specializations.
- How about that usability expert who is passionate about the way your customers navigate their way through your documentation set? Have them design the look and feel of your deliverables.