The TCANZ committee members, those tireless workers for technical communicators in New Zealand, are currently kicking around ideas for a theme for the next conference (September/October 2014). Themes are good – they provide a focus and framework for the marketing and the speakers. One idea that is gaining some traction for the 2014 conference is Communicating Change. In this blog, I want to explore this idea and see what others think of it.
Every day, technical communicators are describing something that will mean change for their end-user. Of course, this isn’t implicit in every TC project – but it is perhaps implicit in enough of what we do to be an area worth exploring for the majority of our profession.
Here are some examples of TC projects that will involve change for the end-user:
- Writing procedures for using a new computer system – leading to some degree of change, frequently a profound degree, in the user interface and processes
- Writing procedures for using an existing computer system after the next major software release, once again, potentially leading to new ways of doing things
- Updating or introducing new policies, standard operating procedures, forms to the business – potentially leading to new ways of doing things
- Writing a manual for a new gadget – even if they’ve had this type of item before, this gadget is new and involves change for the user
- Migrating existing documentation to a new medium, for example PDF to HTML; ringbinders to SharePoint; newsletters to tablets – requiring a change in behaviour and habits
Communicating change to a receptive audience is relatively easy – if your documentation is describing long-awaited bug fixes or system improvements, for example. But what if the audience is not receptive? What if the audience feels threatened, perhaps because the change threatens their job, their self-esteem, their comfort zone? What if they feel the system is changing for the worse? What if the change you are helping to introduce is going to force them to learn something new when they don’t want to? Or what if the audience is receptive – they know they need to install a new router – but it’s annoying to have to come to grips with one that’s a bit different to last year’s model?
These are not unusual situations or challenges for the technical communicator. True, it is not generally a burden we face on our own; we’re part of a team of marketers, IT, quality, and comms people. However it is often our artefacts that will take the user from A to B – a job that is much easier if we can understand how best to support and motivate change.
How helpful do you think it would be in your role to attend a conference that talks about how we communicate change, and look at some case studies? Have your say below.