The mantra of every Technical Communicator is, “Know your audience”. If you don’t, how can you know what they need? Yet I constantly find myself having to justify asking this question. Just the other day I took part in a conversation that discussed changes in the way we delivered our help. Whilst people discussed the pros and cons of different delivery methods and content style, I only had one question to ask, “Do we understand who our audience is?” The problem was, no one could conclusively answer with a, “Yes!” response. Yet I took comfort in the fact that we knew a lot more than we realised. I also believe we are not alone in having this problem.
Our team of Technical Writers produce lots of content for a variety of specialist software applications aimed at the scientific and research sectors. Like most products, there are a variety of documentation deliverables. Some are online. Some are only distributed on request. Some are embedded in the product. In short, it is a real mix. We are complemented by people inside our company on the documentation’s quality, so we must be doing something right. Our problem is that this type of feedback is coming from the wrong people. Without knocking that feedback, after all any feedback is valuable, but we rarely hear anything from our customers.
Will the real audience please stand up!
Some Technical Writers are lucky enough to have access to their customers. My very unscientific study, suggests most do not. Why is that? Arguably there is no single answer. A lack of management buy-in? Maybe it is us not being pushy enough? A lack of resources? Whatever it is, the status quo is unlikely to change unless we initiate the process.
In our team we know we have users. We know how many licenses we’ve sold. We know the companies that bought them. So in theory it should be easy to join the dots.
We occupy part of an office with our Product Consultants. They spend a lot of their time with our customers; the very people we want to know about. The same goes for our Help Desk and other departments with everyday customer contact. They know our users better than us. They know the problems they face. If you are having difficulties getting access to your users, start with these departments. You’d be amazed at the information they have.
The real thing
There is nothing like speaking to people first hand. If you get the opportunity to speak to your users, do not turn it down. With some preparation you can easily gather intelligence about your work that would take much longer to gather any other way. It may also be subject to verbal “editing” by the person telling the story.
Last year I managed to get access to key contacts at four of our large clients. The interviews I arranged with them was enlightening. They more or less confirmed my suspicions. We had long thought that the typical end user documentation we delivered, whilst not be entirely useless, was being under used. The statistics we get back from our Adobe RoboHelp Server installation suggested that. The vast majority of hits were either in areas covering administrative tasks or in new functionality in each release. What is more we could surmise that most of the hits were from our own staff educating themselves.
Why should this be?
It is said there are damn lies and statistics. It is also said that statistics can’t lie. You just have to dig sometimes to reach the real context behind the figures. There is no easy way to do this that I’ve found. It takes time, effort and occasionally bribery if you need assistance. I’ve found offers of a certain supermarket’s Cappuccino Cake often encourages participation.
Most of our applications are highly customisable. So by the time our Product Consultants have finished advising our clients on their installation, it looks very different from the vanilla installation. Key amongst the customisation is what the application elements are called. This makes our job difficult. If we don’t know what the users call things, how can we provide documentation in the terminology they use? Somehow using topic titles like, “Creating an Experiment / Study / Protocol (delete as appropriate)” doesn’t seem right.
We are not in a position to produce customer specific user guides. Besides it is easier for our clients to use our content to produce their own User Guides for their users. Following their initial training by our Trainers, the super users typically create a user guide covering their use cases and terminology. Once that is done, they update it after each release after looking at the help documentation to understand how the new functionality works.
Such a discovery could be soul destroying for some. For us, it told us a lot of what we needed to know. All we need to do now is tailor our content accordingly.