Many software companies give their technical writers the responsibility for creating a documentation strategy. While it can work well at times, it often ends in a huge mess. Even where the technical writers are well up to the challenge – many are – they frequently don’t get the backup they desperately need.
Technical writers aren’t omniscient
To properly develop any strategy, a person (or team) needs to know a lot of seemingly-disconnected information. Marketing, management, and user data is all needed. Generally, the technical writer doesn’t get this information – or doesn’t know what to do with it if they do.
How do you develop your software strategy?
I rarely meet Product Heads who leave their software development strategy up to their software engineers and coders. Good ones will take ideas, sure – but strategic decisions are made with a combination of market research, team input, and a long-term plan.
Why is documentation different?
Spoiler: Documentation shouldn’t be different. Often I find that managers are uncomfortable about their software’s documentation. It feels a bit weird and unfamiliar, like Great Uncle Albert who says the oddest things after a couple of beers at Christmas. But on a high level, documentation strategy should mirror software strategy: it requires market research, team input, and a long-term plan.
The elements of documentation strategy
Today’s documentation options offer so much opportunity for us to research how and why people use it. Website analytics measure which pages are popular, and how people found them. We can record the search terms people are using on our website and on search engines. We can see how long someone stays to look at an article, or at which point in a video tutorial most users bail. And we can ask users about their experiences with our documentation. Did it help? Did it suck?
Traditional forms of market research are also useful. We can look at our target market and find out how they’re consuming content, where they find educational materials, what sort of language they respond to best.
Don’t underestimate your team’s ability to come up with great ideas to refresh your documentation suite. They know your company well, and they’ll often have definite opinions on what they’d like to improve.
In some ways, this is the most important aspect of documentation strategy. Where are you now? Where do you want your company to be? How are you going to get there? How can your documentation support and progress your business plan?
For example: You want your company to become known in a niche market as an innovator that creates products people didn’t realise they needed. Your documentation should be innovative and answer users’ questions before they ask them. It might sound impossible, but that’s a failure of imagination.
What part should technical writers play?
The short answer is: it depends. ‘Technical Writer’ is a job description that spans a number of skill sets. Some tech writers are detail-oriented to the point of having no interest in the bigger picture. Some prefer to focus on the design stage, once a brief has been provided. Others want frequent engagement with users, and have a lot of pertinent, useful data to offer. Some know pretty much any tool and documentation platform ever created. Still other technical writers are all about developing good documentation strategies – and these last are the people that you should have leading your documentation strategy development.
Documentation strategy needs a team
While a big-picture-minded technical writer is a good choice to lead the development of documentation strategy, they shouldn’t be doing it by themselves or with a team of documentation specialists alone. Make sure they get input and help from marketing and management departments. Then they can get the information they need to push your documentation in the right direction.