Shannon Greywalker's Blog

In my professional engagements, I’m a huge evangelist for minimalism in technical communication. So much so, that I’ve spent the past 7 months codifying the first publicly available, detailed methodology for authoring in a pure minimalist style. I’ll be officially rolling out this guide (for free to all) in another month. It’s been mostly finished for several months now, but I’ve been holding off while fine-tuning some details with an entire hands-on release cycle at my present company, wherein my doc team has achieved the following in a mere six months in an agile environment:

• Completely refactored our authoring methodology from traditional “best practices” to pure minimalism, using a detailed methodology/style guide that provides comprehensive reference and training for new writers.
• Completely refactored our source authoring from traditional siloed FrameMaker and RoboHelp to fully collaborative Confluence.
• Developed a nearly push-button method for exporting from Confluence, importing into RoboHelp, and generating/publishing WebHelp for our product that seamlessly merges our new Confluence-based minimalist user doc with the few remaining legacy RoboHelp projects that we’ll completely phase out in the next release.
• And this is for a product whose UI and macro/micro features and functionality is heavily tailored for nearly every customer installation, which is incredibly challenging to document. (Minimalism offers the best answer to this tough problem, and I cover how to do this in my upcoming guide.)

In my methodology, I originally focused on the four main principles that John M. Carroll espoused in The Nurnberg Funnel. (I feel that the few other principles he specifically calls out are just nuances of these four.) Briefly, my paraphrased version of these four all-encompassing principles (with acknowledgements for some other fine luminaries in the field who have expanded somewhat on Carroll’s original wording and ideas) are:

• Anchor instruction in the job domain
• Less is more
• Eliminate sequence
• Expect user error and provide recovery instructions

My methodology also calls out two additional principles of my own. I feel that Carroll probably expected that these didn’t need to be specifically called out in his original work, because one would expect that these are covered by “best practices” in technical communication. But in my experience, “best practices” are not well-codified at all, and every writer has their own ideas about what that term means. So to reduce ambiguity, I spell them out with lots of detail and examples:

• Reduce ambiguity
• Increase brevity

The real subject of this article is the new principle I’m about to add to my methodology as well:

• Increase acquisition speed

Looking back at the concrete methodology I’ve developed over the past few years (through a lot of experimentation and iterative refinement on real projects), I realize that this new principle was always a fundamental driver behind my specific methodology and presentation style. What I lacked until now were compelling arguments for why this is an important principle to observe.  Well, a wonderful video created just a few weeks ago has finally been making the rounds in the Social Web, and when I watched it just now, I had a wonderful moment of satori. Spend 10 minutes to watch this video (worksafe) before continuing.

At roughly the 7:40 mark, the video points out something that I’ve blogged about before, which is essentially that most of us long-experienced technical communicators come from a generation that was trained to be comfortable with absorbing information at a much slower pace, and in a much more passive format, than people even one decade younger than us would tolerate. And the folks in their 20s and younger now? Forget it. The typical “best practices” that most technical writers still adhere to are completely out of touch with the sheer speed at which 20-somethings and younger expect to be able to absorb information.

I like to think that despite my age, I’m actually more in sync with the reading (or should I say “skimming”?, lol) modes of the 20-somethings today. While that might be wishful thinking, I do pay a lot of attention to any news/research I can find about the ways that kids prefer to learn and engage with information of any sort, which is one of the things that pushed me in the last decade to keep innovating and finding ways to improve on traditional technical communication practices and steered me quickly towards minimalism once I learned of it (15 years ago? Hard to remember now). But as evidence: I’ve routinely had 4 screens at work for nearly two years now: my MacBook Pro, my iPad (formerly my iPod Touch), and two screens for my company-provided Windows workstation/laptop. I keep the best social aggregators I can find running full time. I wade through a lot of information input every day. I consider email (even company email) to be a nuisance and mostly spam to be checked only a few times per day. (And countless messages go unread if the subject line doesn’t scream “I’m important!”.) I love Campfire and loved Google Wave (even though they blew it) because to me the concept of “centrally-hosted conversations” is so much more efficient than the tired old paradigms of face-to-face meetings and point-to-point communication shuttling.

Where am I going with all this? I feel that I fully understand the critical importance of evolving our technical documentation in any direction that increases the acquisition speed of the specific information that readers are seeking when they crack open our technical documentation. The old paradigms for writing books and chapters that are intended to be read sequentially just have to go. They are epic fail to a near-majority of your current audience, and the full majority of your near-future audience. This means we have to get very creative on three fronts:

• More pervasive use of inline links to enable cross-navigational browsing. It doesn’t matter that recent studies seem to indicate that readers retain less information when they aren’t forced to read sequentially. The function of our doc is not to teach, but to answer spur-of-the-moment questions. If readers need that same information again in the future, they’ll find it that much faster the second time. They don’t need to remember it; they only need to remember their strategy for finding it.
• More mechanisms for skimming and scanning for domain-oriented keywords to quickly find the specific information they seek.
• And the reflexive version of the preceding point: more mechanisms for entirely removing systems-oriented language and organization. Modern readers have no desire nor patience to learn your system. Instead, they only want to know how make your system support their immediate domain goal.

As always, I hope you find essays like these informative and useful. I specifically avoid a minimalist style for these blog posts because these are focused on teaching and learning, not giving you quick answers. There will always be a place for more traditional discourse like this, just not in most of our technical communication products. Watch in the next month for the unveiling of my new, state-of-the-art methodology for minimalist authoring.