How meaning works in technical communication

Considering how meaning works in communication in general, it should be easy in technical communication in particular, because several parameters are fixed.

Last week, I asked whether we actually create meaning in our documentation. Today, I take a closer look at semiotics to find out how meaning is created in communication – and specifically in techcomm.

How meaning gets transmitted in communication

Semiotics is a theory that explains communication as the production of meaning between people who exchange messages in cultural contexts. Semiotics aims to explain how communication is meaningful for a reader. (For much more on semiotics, check out Daniel Chandler’s good introduction Semiotics for Beginners.)

Note that the reader is not just a passive recipient of the message, but the active participant who constructs the meaning of a message. That is not to say that the meaning is whatever the reader wants. Rather, the meaning arises from how readers interpret the signs according to shared common conventions. For example, a user will – more or less – assume that a user manual contains photos or schematic images that represent the layout of the product, not an ideological statement, and try to create meaning accordingly.

Semiotics can get quite complex, due to all the moving parts:

• Signs, such as words or even images, can lend themselves to creating different meanings at different times or for different groups of readers. (Think of ideologically, religiously or politically charged words or images.)
• Semiotic “codes” can make you feel a member of the group, like your own regional dialect, or they can exclude you, like academic jargon. Whether you feel included or excluded influences your understanding of the message and the meaning you take from it.

However, technical communication suffers less from these shifts and ambiguities, because a lot of our signs and codes are restricted and well-defined. Or are they?

Why meaning seems easier in tech comm

Much technical communication can avoid some of the semiotic pitfalls because it addresses a limited, rather homogenous audience. We can assume a general willingness to learn the applied “code” of descriptions and instructions such as a user manual contains it. A manual can presuppose a certain vocabulary or define it in its glossary. The context is confined to the intended tasks of the products, and the expected outcomes of the tasks should be clear.

With all these major restrictions on communications in place, the user’s path is confined to a tunnel, and all that is left for the manual to do is to put in some lights and a railing to safely guide the readers through.

– If it was that easy, we wouldn’t find meaning in technical communications so elusive – and we wouldn’t despair to get users to follow the documentation. So our daily experience tells us that it doesn’t quite work that way.

– I’ll explore this problem at my presentation “Addicted to Meaning: How Good Technical Communication is Like Bad Magic Tricks” at tekom/tcworld in Wiesbaden on Tue 23 Oct at 1:45 pm. In the meantime, feel free to leave comments or questions below.

Advertisement