Clarity vs friction in technical writing

I believe that everyone who works with technical writing should read something about instructional design at some point. If not to become an instructional designer, at least to grab a picture of the techniques used to teach adults. After all, in the end of the day that’s what we’re doing.

So for the past two months I’ve been leafing through books and articles that try to recommend ways to design, implement, and evaluate learning experiences, in hopes of finding insights that help me in my job. And insights I’ve found.

One of them made me contrast two of our daily efforts: first, the one to be as clear, concise, and straightforward as possible; second, the one to escape boredom and create enough friction to make the learning experience more interactive and take the learner out of her passive position, stimulating the cognitive load.

Some of the ways in which such friction may be created, according to the author of Design for how people learn, are:

• Tell stories;
• Surprise the learner;
• Create social interaction;
• Show the learner “shiny things”;
• Make the learner explain the subject.

However, how do we do any of these without losing clarity or at least objectivity? Is it possible to tell stories in documentation? Is it feasible to expect the learner to engage in the learning experience with a more active approach?

I believe it is, but only to a certain point.

When we’re dealing with a classroom or a textbook, the list of strategies that may be applied feeds on a variety of techniques that take into account the way our brain works. These strategies will tell you to turn the conventional teaching approaches upside down, and some of them are so counterintuitive that I’m often tempted to try them.

However, the technical writer has much more limited wiggle room. And I see one main reason for that: we are usually dealing with a learner who has no time to lose.

Chances are she has an urgent matter in hands and wishes for a direct answer that simply solves her problem, which makes it hard for us to focus on long-term memory, cognitive load, and other fancy stuff. What the learner expects is words in just the right form and amount to make her perform an action.

That doesn’t mean we have no room at all to try and get our users through a richer learning experience. But we always need to consider the expected effect. If you’re working on troubleshooting content, go for clarity and avoid experiments.

But if you’re building a Getting Started tutorial, maybe you can find ways to insert a story, a surprising hands-on experience, or even some humor. It will just take more creativity than usual.

Read more on Tech plus Com.