Reading :: Wicked, Incomplete, and Uncertain

Wicked, Incomplete, and Uncertain: User Support in the Wild and the Role of Technical Communication
By Jason Swarts

In the late 1980s and early 1990s, technical communication programs grew precipitously across the US. In part, that's because of the PC Revolution. People were suddenly buying computers and software, and they needed to know how to run them. Software interfaces were not yet standardized. And (don't underestimate this factor) people were not yet used to paying hundreds of dollars for digital media—and software manuals made the boxes heavier.

Yet, as John Carroll noted in 1990, computer documentation was inherently limited, because writers simply could not cover every use case. He advocated the "minimal manual," focused on exercises that could help readers apply general skills to their specific problems.

Fast forward to the late 2010s, and writers really can cover every use case. But these are not necessarily trained writers: They're other users, communicating with each other on forums and via social media. As Swarts says, "We still need help, but increasingly we are ignoring manuals because our purposes have grown beyond what manuals are capable of addressing" (p.3).

Swarts methodically makes his case throughout the book, drawing on his (meticulously planned and executed) published studies as well as those of others. Through this work, he demonstrates how the object of technical documentation has shifted; how tasks related to stabilized situations have given way to "wicked problems" in unstable situations; how expertise has been decentered across different users (and here he uses stasis theory to demonstrate how users in tech forums collaboratively define and attack a problem); and how new genres of help have emerged to address these problems.

And yet, he argues in the last chapter, there is still a place for technical communication as a field:

technical communicators need to be a different kind of expert, less a 'throw-it-over-the-wall' expert and more like a facilitator or network maker, someone who is skilled at finding the right information and making the right connections and creating the right protocols and formats to meet the user's needs. (p.150)

Although the skills of traditional technical communication—clear style, strong organization, chunking, signaling, etc.—are still useful and important, for technology documentation, this facilitation/curation role is much more important. Swarts (as usual) nails it here. If you're interested in technical documentation, definitely pick this book up.