Being meaningful is an essential, but elusive feature of good technical communications. Yet being meaningful in technical communications is just as essential as being correct and clear, concise or consistent: Understanding how and why communication is meaningful can help you to make your documentation more effective and to make your product more useful.
What is meaning?
Information theory suggests a hierarchy of information which proceeds from data at the bottom via information and knowledge to wisdom at the top. For example:
- Data is the sheer fact that the Microsoft Office 2007 software has an “Office button” icon in the upper left corner.
- The information is that this icon gives you access to functions such as opening, saving and printing a file helps you with generic functions.
- The knowledge is that this functionality has replaced the File menu you’ve been used to. This adds meaning and supports your active experience.
- The wisdom might be in the affirmation that nothing lasts. Or that Microsoft has flipped-flopped when they abolished something as sensible as the File menu – only to bring it back in Office 2010…
So meaning occurs at the knowledge stage in this hierarchy when you make sense of data and information, when you “connect the dots” into something that you can apply purposefully. Meaning gives answers to questions such as “So what?”, “What does this mean for me, in my situation?” and “Why should I care?”.
Why should technical communicators care?
Technical communicators should care about meaning, because we are in the business of creating meaning and transmitting it to users. We can provide all the data and information we want, if it’s not meaningful to customers, it’s wasted and dead. Any time documentation fails, it’s either because meaning has not been created or not been transmitted successfully. Documentation that merely informs the user “To print a file, click the Print button” does not support any active experience. It does not create any meaning, if it omits the context, such as the task the user may be engaged in, the prerequisites and the expected results of the user’s action.
– How can we ensure that our documentation is meaningful? Should we be thinking about meaning explicitly? Or is it enough to know our audience, use personas and create task-oriented documentation? Feel free to leave a comment.
Filed under: cognition, personas, technical communication, usability, users |
Kai's Tech Writing Blog 
I think that this goes even deeper than what you eluded to; namely, that at some level technical writers have an ethical duty to examine the context in which they write and to whom. We can’t automate documentation to merely push data without taking into account how users (and even non-users) will use the information we disseminate.
Hi, Fer, thanks for your comment and sorry for the delay in replying (it’s conference season… 🙂 ).
I agree that meaning is just one of the underpinnings of our work and that the ethical aspect falls by the wayside probably even more often! It’s just that I’m currently exploring the semiotic side of the issue, how meaning works and what it means in tech comm.
I’ve seen that you’ve recently examined the ethical aspects on your blog (if you’re not Fer, check it out at http://ferswriteshoe.wordpress.com/tag/ethics/ !).
I guess you know about the three books on the issue from the late 90s:
– Ethics in Technical Communication by Paul M. Dombrowski and Sam Dragga
– Ethics in Technical Communication: Shades of Gray by Lori Allen
– Ethics in Technical Communication: A Critique and Synthesis by Mike Markel
For a post-structuralist Foucauldian take on meaning, power and authority in tech comm, check out “The Tecnical Communicator as Author” in Critical Power Tools: Technical Communication and Cultural Studies by J. Blake Scott.
[…] Weber, asks the question that all technical writers should ask themselves in his article titled But do we create documentation with meaning? Share this:TwitterFacebookLinkedInPinterestLike this:LikeBe the first to like […]
Kai, one quibble: many times documentation fails by not treating the correct issues at all.
But yes, the rest of the time it fails because it provides statements but not meaning. I think you and I are barking up the same tree here. In my quest for the “narrative minim” (http://everypageispageone.com/2012/09/11/topic-size-finding-the-narrative-minim/). I am arguing that people are frequently slicing content too thin in a quest for reuse, and then putting it back together in a way that does not create meaning. The downward limit for the size of topic that should be presented to the reader is the narrative minim — the smallest unit that actually conveys meaning.
Of course, there is also the problem that a lot of documentation does not convey meaning because it is simply badly written or badly organized, regardless of how bit the units of content are.
Thanks, Mark, for your comment. I’ve added my reply to your post. Everyone, mosey on over to http://everypageispageone.com/2012/09/11/topic-size-finding-the-narrative-minim/#comment-70082