Recently a coworker asked me to help him fix a complex Word document containing important information for our company’s operations.
“Whenever we try to update this document, the numbering sequence goes out of whack,” he said. “Can you help? Also, it doesn’t look as good as the stuff your group produces, so anything you can do to improve it would be great. ”
I agreed to help out and before I could say, “white space,” was plunged into the fourth dimension of tech comm — document design.
Document design is probably the least discussed area of technical communication, yet it’s the one where most of us require the most assistance.
Early technical writers didn’t have this problem. They wrote their copy on a typewriter and turned it over to a typesetter.
With the advent of desktop computing, typesetting and document design was transferred to the technical writer — ready or not!
Of course, technical communicators at large companies have the advantage of a design department that sets the standards, ensures proper branding, and may even provide assistance template design. But lone writers and those of us in small or dispersed groups must tackle design on our own.
Therein lies the problem. Most of us who stumbled into this profession are either writers who enjoy technology or technology people who enjoy writing. But we are not designers. Information design (a fancy name for technical communication) does not equal document design.
We can deftly chunk information; put it in the proper order; quickly distinguish between reference info and procedural tasks; apply minimalism in our narrative; and index thoroughly and thoughtfully. But if we neglect our fonts, styles, alignment, format, illustrations, headers, footers, and callouts, our audience struggles to absorb the content.
Every technical writer I’ve met is an autodidact when it comes to document design, but we manage to pull it off because our managers and many of our customers know less about design than we do. This means that even a meager attempt to employ basic design principles results in a WAY better document than most people can muster.
Problems arise when several self-taugh tech writers in the same department are challenged to agree on best practices for designing their templates. Fierce debates are likely to ensue because no one has enough authority on the subject. I myself am a scarred veteran of such battles including the hard-fought “Defense of the Round Bullet,” which I won and the “Campaign to Adopt Arial Narrow,” which I opposed and lost.
For this reason at STC conferences, sessions on document design (and they are few and far between) are mobbed, because we are hungry for more information — and secretly hoping we can return home with more ammunition for the next design skirmish.
I’m happy to say I was able to utterly transform the ugly document presented to me by my coworker. It was greeted with joy and praises at a subsequent meeting of employees who use the document regularly.
Here are my primary sources of information:
We had the honor of hosting Jean-luc at our Currents conference this year.
You can read his papers on his Web site, but you really need to experience him in person. He engages all the participants in the discussion and instead of lecturing at you, draws you into solving design questions. You walk away with some simple, but profound principles that will serve you well in any design dilemma.
Karen A. Schriver’s Dynamics of Document Design.
I’m rediscovering this book after reading (some of) it ten years ago. Schriver shares some interesting insights her team gained while researching document design. She also has a wonderful timeline showing milestones in document design over several decades and how they relate to other historical events.
I’ll write more on this soon.
How did you learn about document design?