'Nobody Reads Documentation?'

Risk-taking researchers are a rare breed in the usually conservative academic world. But every so often, one fearless daredevil shakes up the research pond by tossing out a provocative article title. Retting  was one such rebel (also an experienced information designer), and van Loggem  couldn't resist taking the bait. But instead of just skimming the surface, the technical documentation specialist submerged herself in Retting's article only to discover a surprising misconception about the very meaning of the word 'read.' She says: 
 

Contrary to popular belief, software users do read the documentation. Depending on what exactly is counted, the numbers vary between 26% and 80% of information-seeking behaviors.
 

Uncovering the mysteries of reading in technical documentation requires delving deeper beyond the murky waters of 'information-seeking behavior.' First, we need to understand the motivations behind why users consult technical documents in the first place. 

What does the user want?

Let's say your user is an aspiring sailor about to embark on the vast open seas who suddenly realizes the almighty Google cannot aid them in finding the nearest tropical island, with a treasure chest buried somewhere in the sand. After swallowing the bitter pill and not letting themselves be discouraged too much, they reach out for the 'Savvy Navvy' user guide.  

Ideally, the documentation wouldn't further discourage them and provide helpful advice on a pretty complex task like navigating a boat. How do you ensure the user sails safely without knowing their bearings and prior knowledge of sea excursions? 

Jonatan Lundin  – who conducted an extensive study on the use and design of technical information – provides a map of the many scenarios where a user may seek assistance: read-to-learn, read-to-do, and read-to-learn-to-do. Put yourself in the sailor's boots for a change, alright? And imagine waking up on a wobbly ship and discovering you're…let's say, a sailor-slash-pirate now. Searching for and learning about the best available eye patches to cover your still healthy eye is akin to read-to-learn type. Or, consider a situation where you need to solve a specific task, like when an angry captain screams at you from the top of their lungs: 'Haul on the bowline, you bloody scallywag!' – this is a learn-to-do type. Finally, read-to-learn-to-do combines the two motivations, like classroom training that, hopefully, explains how you suddenly became a pirate and also supports you in learning how to organize an excursion to find the valuable prize; or at least how not to anger the scary captain by executing their commands.

What does the user really, really want?

Lundin then continues to cite an information design expert,  Albers,  who mentions yet another motivation worth considering: 

Albers (2012) makes the case that many communication situations have shifted to complex situations, and thereby technical communicators ought to focus on designing technical information that supports reading-to-decide.

A reading experience that lacks a guiding structure and context leaves some users adrift in a sea of unfamiliar information. Writing that supports reading-to-decide, according to Albers, 'revolves around information seeking and decision making' of the user. Once people obtain information, they must interpret and implement it. This entails shifting from producing instructional texts on task execution to composing documents that consider people's information requirements and how they integrate the knowledge gained through reading (Albers 2012, p. 171).
 

Authority lost

The minimalist approach, masterminded by Carroll  – a distinguished Information Sciences and Technology professor – puts the user in the decision-maker captain's seat. Empowered with their prior knowledge, they navigate around purposeful gaps set by the authors, seductively enticed by the minimalist siren song. This allows the user to freely explore the rich features described in the manual while seeking answers to their questions. Delivered through an online database, this documentation provides a personalized experience. The user can almost be heard confidently declaring with a smirk, 'Look at me. Who's the captain now?'

Is minimal always better?

With its minimalist, modularized design, technical documentation boasts many advantages – like the ones you've spotted above. But it also creates its fair share of challenges. For instance, Swarts,  a Technical Communication Professor at Carolina State University, tells us that while topic-based content offers speedy access to the information the experienced user seeks, it fails to provide the essential context that novices need to understand.  

In the worst-case scenario, the beginner's attention drifts away, leaving them lost and disoriented, unable to piece together the various pieces of information. This poor castaway user is left to their own devices, stranded on an unfamiliar, treasureless island, reciting a mournful refrain like the one in Whitman's poem, 'Oh Captain, my captain.' Did the minimalist sirens just lure the unwary user into the rocks to crush?
 

Language Compass (or Google Maps)

To ensure the power balance and a fair distribution of treasure wealth on a documentation front comes the first and only second-in-command, Technical Writer. Armed with linguistic background knowledge and an authoring tool, they design the treasure map. In doing that, they perform two tasks: supervise the new boardmen and support the daring captain. 

Some believe that topic-based, minimalist writing undermines the authority of the second-in-charge (or the Quartermaster, in pirate terms). Others think it requires using different means to help users navigate the manual's context-free, intra-, and intertopical waters. 

Such means might involve a Multimodal Metadiscourse, which, like a compass or Google Maps, can help locate, find, and solve the location of a hidden (information) treasure or in seizing the bountiful cargo from a fancy yacht. 
 

tl;dr

Curious about how a user's motivation affects their reading behavior? Wondering why minimalism isn't always the solution to your documentation woes? Interested in how linguistics can improve your design? Our blog tackles these questions and more! Read away, and stay tuned for more to come.

Authority regained

Although the principles of Technical Writing remain the same, the need for Technical Writers to take back control over how their documentation is consumed has become more pressing than ever. With so much information available, it's essential to ensure that readers can understand the information in a way that works for them, regardless of the delivery medium.

That's where multimodal elements come in. In the next blog post, we'll dive deeper into how Technical Writers can use multimodal metadiscoursive elements to create reader-friendly documentation. Stay tuned for more!