The Slow Word movement for technical documentation?
Would a “Slow Word” movement be useful for technical writers? Hmm. Lots of argy-bargy potential here. I’m just going to write up some musings. You’re sure to have some thoughts too. Drop a comment. Slowly, take your time... 😉
Trevor Butterworth has written an article at Forbes.com entitled “Time For A Slow-Word Movement”. He’s referring to media publishing in general, rather than technical documentation in particular. He points out the fast-moving, internet-savvy, click-it-and-go world our readers live in, and says that it’s affecting their ability to read and enjoy published works. He suggests a “Slow-Word movement”, comparable to Slow Food.
I love the way Trevor uses language to illustrate and embody his thesis. Reviewers and commenters have called his language “curmudgeonly”, “baroque” and “grandiloquent”. Yes, but that’s the point! I don’t agree with all of what Trevor says, but his article sure got me thinking.
How much of what he says can we apply to technical documentation? Would we, and our readers, benefit from slowing down, smelling the daisies, writing good manuals and reading the manuals? BTW, Tom Johnson says it’s OK if no-one reads the manual. 😉
The whole world’s gotta slow down. Or not.
Trevor writes about his idea of a Slow Word movement,
“The idea of consuming less, but better, media–of a “slow word” or “slow media” movement–is a strategy journalism should adopt.”
He emphasises the (lost) pleasure of reading. I think it’s our duty and our calling, as technical writers, to provide user assistance that is a pleasure to read. Or watch, hear, consume in the way the reader prefers.
So, we should all slow down. But isn’t the whole point that people need to read stuff fast these days? The readers of today skim our documents, web pages and blog posts. I do it all the time. Trevor says, “In short, a relentless, endless free diet of fast media is bad for your brain.” No, I don’t think so. That’s a generalisation. But I do think we need to fight for our place in the multi-tasked, information-overloaded brain that is our reader.
Quick, grab that reader
I’d like to highlight an aspect of the “Slow Word” message: We don’t want to write slow words. Rather, we need to write words (or whatever) that slow our readers down!
(From now on I’m going to refer to “documentation” and “words”, but I’m encompassing all the various media we use. Instead of just the written page, we can use online help, videos, audio, e-learning – whatever form our readers need.)
We need to slow people down just long enough to get our information across. Otherwise, people will rebound off our page, hit Google, ricochet aimlessly around the intertubes and then give up, frustrated and testy, and apply a second-best workaround or buy a competitor’s product.
How do we clamp our readers down? Ah, there’s the rub. That’s where our training, skill, enthusiasm and creative skill come into it. I think it’s nothing too scary, but rather a realignment of what we’re already striving to do:
- Keep our documentation concise. This takes time, re-writing, crafting and review. That’s where “slow” comes into it. The Slow Word movement is all behind the scenes.
- Present our content with flair. It must be a pleasure to read, watch, hear.
- Add a surprise here and there. Haydn dude, you rock. I don’t think it does any harm to let a touch of personality, a delight, a giggle creep into our documentation. Here I’m talking about the sort of technical documentation most of us are doing, predominantly in the information technology world. There are obviously documents where levity would go amiss.
- Know our audience. People of very varied levels of expertise come across our documentation via the web and various media. If we had the time and resources, it would be awesome to write a documentation suite targeted to each level of expertise and each medium. Since we seldom if ever have that luxury, maybe the best way is to create short, discrete documents. Like building blocks that people can choose and build on as they need them. The skill lies in chunking the information right and in making the building blocks easy to find.
- Focus on the purpose of the document. We’re often asked to include all sorts of dross on our pages, such as legal messages, product advertisements and cross-selling blurb. These will tire and distract our readers, who are already battling the stream of tweets, RSS news items, IMs and email popups flaring up all over the planet. Our content must be king.
- Grab the reader’s attention where it’s at. I’m going to escape from this bulleted list now, because I have a fair bit to write about this one.
Grab their attention where it’s at
The Slow Food movement aims to “counteract fast food and fast life, the disappearance of local food traditions and people’s dwindling interest in the food they eat”.
Instead of counteracting the fast peppy media world our readers inhabit, I’m thinking we should jump in boots and all, kick the borders outwards and put our content in the middle. Up with technical documentation, in whatever form it takes. Build on the old traditions, ride the new ones and create our own. And we’re doing that! Technical writers are experimenting with Twitter, video, wikis, structured authoring, collaboration and feedback mechanisms, you name it.
A glass of wine and something to believe in
The Slow Food movement aims to “bring together pleasure and responsibility, and make them inseparable.” Yes, that works for the documentation too.
Going back to Trevor’s Slow Word movement: Our readers need “something to believe in rather than rail against, something elegantly simple and bipartisan that has sufficient aesthetic compulsion to sound pleasurable rather than penitential”.
OK Trevor, you gotta admit, that’s a trifle long-winded. 😉 But yes, the message applies to technical documentation too. We want content that is clear, concise, correct, attractive. Not a pain to read. For sure, “it’s simply unrealistic to expect the public to read [manuals] as a daily personal moral commitment to [documentation]”.