I’m currently in the midst of some thinking. I’m thinking about how we can improve what we do, how we measure those improvements and ultimately how we make a step change in the quality of our output.
Oh no, I used that word, didn’t I.
Quality.
At this point I will veer away from that word, for fear of plunging headlong into the land of metrics, and instead outline some of the things floating around in my head.
To improve the perceived quality of the information, there are some things we can do:
- Improve the navigation
- Improve the findability of the information
- Improve the technical accuracy of the information
- Improve the completeness of the information
Navigation and findability are linked and we have some ideas on how to tackle those through better indexing, better understanding of the structures, addition of signposts and all those good things.
Improving the completeness and technical accuracy can be a little trickier to nail down though. No product documentation is ever complete but by improving our approach to collating information and the questions we ask, we can take start to make improvements, those same questions should also help improve the technical accuracy, as will a beefed up review process.
With all of this in mind, we will be running some workshops early February to revisit the basics. We will cover off every aspect of how we work, and step through how we can improve the outputs of all our hard work (well, all the hard work the team do, I mostly try and keep out of the road thesedays, they seem to work better that way!).
I’ve been with my current company for four years and, for each of those years the team have managed to make significant improvements in a variety of areas. Year One, the first members were hired and we set about improving the quality of the content, Year Two we launched our developer website as a means to make it easier to access the content we were creating (that website is about to relaunch in it’s third iteration), Year Three we transitioned from FrameMaker to Author-it and publish our Knowledge Centre to the developer website, and this coming year… well, time will tell.
I’ve no idea what we will decide to do, what processes we will change or adopt, what new ideas and challenges we will set ourselves, but this part of the job is the one I enjoy the most. Everything is fresh, new and exciting.
Roll on 2011!
Sometimes, completeness conflicts with quality. (By ‘quality’, I mean primarily ‘usefulness’.)
Some problems are more important than other problems. For example, if a user cannot log in to software, then all other problems are not applicable. Some problems are more difficult than other problems.
Sometimes, if you document a product completely, instead of focussing on the parts that cause problems for users, you decrease the quality, because users have help for things that they do not need help with, and they do not have sufficient help for some things that need much explanation.
Couldn’t agree more Mike, there is a balance to find, and at the moment I’m not entirely sure we have it right. There are some areas we ‘over document’ and others that are lacking.
I do like your definition of quality though, much better that the information is useful and achieving what is required.