Meaning in technical communication at Tekom tcworld 2012
I’m attending Tekom tcworld 2012, in Wiesbaden. This afternoon my friend Kai Weber is presenting a session called, intriguingly, “Addicted to Meaning: How Good Technical Communication is Like Bad Magic Tricks”. Here are my notes from the session.
Kai Weber writes a blog at Kai’s Tech Writing Blog. I’ve met him at a previous conference, and we’ve exchanged frequent comments on various blog posts. I’m really looking forward to this session!
Kai started by telling us what’s in this session:
- What is meaning and why should we care
- How does meaning work in communication and why does it still fail in tech comm?
- How and why we create meaning and how to create meaningful documentation.
What is meaning?
The WKID pyramid:
Moving up from the bottom of the pyramid, you start from small bits of data and move up towards wisdom. We have a lot of data, but little wisdom.
Meaning starts at the information level. There’s much more on the knowledge level. Wisdom is meaningful too, but Kai says he’s not the expert there so we’ll focus on information and knowledge.
Meaning is meaningful and valuable because it allows us to connect the dots and see how something relates to our tasks. It answers the question, “why should I care and what do I do?”
Why should we care, as technical communicators?
What we do is to turn information into relevant and applicable knowledge.
As proof, see our principles and methods: know your audience, and write task-focused documentation.
How meaning works in communication
Kai showed us the Shannon and Weaver (1949) mathematical theory of communication. This is a great engineering model, useful for telephones, for example. But it doesn’t have much about meaning.
So Kai looked around and found the theory of semiotics (Fiske 1990). Communication happens when a listener interprets the signs (messages) from the speaker, based on shared conventions.
Technical communication tries to offer solutions for a number of the problems that semiotics have shown. Semiotics diagnoses problems, such as the fact that signs represent arbitrary stuff. Tech comm says that we should offer definitions and clarify with images and glossaries. Semiotics says that conventions/codes can include or exlude social or ethnic groups. Tech comm says let’s define standard language to ensure accessibility.
Why does it sometimes still not work?
We think our messages, conventions and media are clear. But for a large part of the time, we still misunderstand each other.
Von Foerster (1949) proposed the theory of radical constructivism: there is no meaning but the one created by the reader! He also said that each individual situation is a new beginning, another page one.
The reader ultimately decides what meaning he gets from the documentation.
How we create meaning
We combine our current situation with past experience. The way we do this is by matching mental models. These mental models shape what we think of the world, and how we try to solve problems.
Kai used the example of a restaurant. We all know how a restaurant works. We know how to look at a menu, order food, and solve problems such as when the wrong drink arrives. The model is fairly flexible – we can handle restaurants that are outside, or even self-service restaurants. We’re thrown if the restaurant is completely different, such as one in Japan.
Mental models are slow to change (like the Japanese one) and largely subconscious therefore uncontrollable. Windows 8 is so completely different from Windows 7 that people don’t know what to do.
In tech comm, we have an interesting problem because we are dealing with 2 mental models:
- The mental model of the engineer/designer – which is inert and incontrollable.
- The mental model of the user – which is also inert and incontrollable.
These two mental models meet in the system, and it is up to us to translate.
Why does it work some of the time? Because people are addicted to meaning.
Because we are addicted to meaning. People want to get their stuff done, and are really inquisitive about what things mean and how they work.
Examples: Google for “mondegreens” to see how we try to make sense of lyrics. Or see how we look at logos and try to make sense of them. Kai talked us through how we try to make sense of the coloured image of an apple, by Marcin Wichary.
People also seek order. We want to know how stuff hangs together, and how we can connect the dots.
What does it mean for meaningful user assistance?
It means this:
- Our documentation must be relevant to the user and situation.
- Or show us a workaround.
- Or an explanation of why stuff is so weird.
- Or at least give us some sympathy.
The most popular user assistance is help of a friend or colleage. That will give us all of the above four. Second most popular is Google.
Our documentation will offer the first two, but not the last two.
How can we create more meaningful UA?
- Understand how people create meaning.
- Adjust our content to the users’ mental models. See the techniques of user interface designers and user experience designers. Observe user behaviour. Offer several paths, for different tasks and personas. Be respectful of the way users have always done something. You do have to innovate, but be aware of the huge number of users who just want it to work the way it did before, just better.
- Apply minimalism. Help readers to connect the dots, focus on process and outcome, not product. Give just enough information, and encourage them to develop skills. People are usually intelligent enough to connect the dots. For example, don’t tell people to “click Save” or “click OK” unless it’s really important. Encourage people to use the skills they already have.
Why is good documentation like bad magic tricks?
Good documentation doesn’t marvel you with fire and smoke, as did the wizard in the old film “Wizard of Oz”. It helps you by exposing the way the system works – it exposes the wizard behind the curtain.
This was a very interesting, amusing, and thought-provoking presentation. Meaningful. 🙂
Posted on 23 October 2012, in technical writing, Tekom tcworld and tagged #tcworld12, technical communication, technical writing, Tekom tcworld. Bookmark the permalink. 4 Comments.
Thank you, Sarah, for your extensive and faithful notes on my presentation. I’m glad you found it “meaningful”! 🙂 I’d just like to clarify a couple of minor details for our readers’ benefit:
– The “WKID pyramid” is more frequently called the “DIKW pyramid” and even has a Wikipedia entry under this moniker.
– The “coloured image of an apple, by Marcin Wichary” is a photo (by Marcin) of Rob Janoff’s rainbow-coloured logo for Apple Computers – so the different stories of meaning referred to the coloured Apple logo with the bite in it.
Thanks Kai. 🙂
Pingback: First day at #tekom12 « Kai's Tech Writing Blog
Pingback: Tekom tcworld 2012 wrapup « ffeathers