I stood at the front of the class, full of enthusiasm, ready to deliver a training course on a wonderful, new, soon-to-go-live software product. It was a hands-on course with lots of exercises and fun quizzes. I’d worked hard with the project team to make sure we’d keep the focus on relevant features for the different departments who were completing the training programme.
What was missing?
Before we’d even switched on a machine, the questions were coming thick and fast. How will this change my role? How will I work with department x? Where will I find y? And.. why are we doing this?
Was explaining all that part of my job? I was the software expert, not an organisational change guru.
It was my job that day, and in a way, it still is now.
The things you can’t see
Technical communicators create conceptual content as well as instructions. They build visual as well as text-based content. And today, all of this information can be consumed and shared via your web site by people, for whom a product purchase is but a twinkle in the eye of some far away budget holder.
The value that technical communicators bring is not in describing what the user can see, but what the user can’t.
That includes: seriously technical content – how to build a complex customisation that you can’t see yet; and it’s content which answers conceptual and scenario-based questions – how do I relate this to my role, my world, to the thing I have to get done right now?
Today, there are lots of ways to gain insights into the things which your users cannot see clearly, without physically being in the same room as them. However, few come close to delivering an equivalent injection of empathy.
And you’ll carry that with you for a long time afterwards.