“When is reading the real manual faster than dealing with the Quick Start?”, muses Kevin Lossner on Facebook. I believe this tells everything about the idiosyncrasies of software documentation.
Most of the time, software documentation is being done out of fear. Fear that the moment a tiny detail is left out, the omission will be exposed and ridiculed. Or even worse, followed up legally.
Most of the time, software documentation makes the rationalist assumption that every detail written down will be noticed, read, understood, and coherently applied by human users.
This is not true, and what’s more important, not the ethos of Kilgray. We’re known to be good at connecting with our customers, at least I hope we still are. Yet strangely enough, we seem to miss out on this when it comes to the help and manuals of our products.
memoQ professes to be a productivity tool. But the efficiency of a productivity tool goes beyond the performance and the ergonomics of the product itself – it is also affected by how well users are assisted while at work.
memoQ’s help and manuals thus face the same challenge as the tool itself: make the work of users easier, faster, more economic, and better in quality. I wouldn’t say we’re not achieving that. It’s even worse: we don’t know if we’re achieving it. We’re supposed to cut down on the time it takes to learn a feature or a procedure, and cut down on the times you need to turn to Support. That’s been our intention from the start, but I don’t know how well our current materials serve it.
Although I used to do documentation work, I’m new to the position of a technical communicator. It’s never been my primary responsibility before. I think I know the field quite well, so I could make all sorts of vows to improve our documentation in lots of specific ways.
But I won’t make those vows, just this: that improvements will be made, and it will happen through interaction with our users. We have great ideas that could make the user assistance parts of memoQ just as strong as the best features of the product. (User assistance is the jargon for help, manuals, and all sorts of technical documentation.)
Right now, I’m making quick updates to prepare for the next minor release of memoQ – but once that’s done, it will be a time to learn. Learn about how our current documentation is helping – or not helping – our customers, and what we can do to make it better.
Then – let me just repeat my promise: there will be changes for the better, and we’ll be in touch while we make them.
You’re hereby invited to be the judges of that: in twelve months’ time, please remind me of this blog post – if I don’t return to it myself –, and tell me if I made good on my promise.
This post is not meant to criticize my predecessor, Madeleine Lenker. Indeed, Kilgray owes her a lot of gratitude for her great work. I think she did the best possible job within the framework she’d inherited from us all those years ago. But every now and then, a time comes when you need to break with tradition.
![Balázs Kis](https://blog.memoq.com/hubfs/BalazsKis2.jpeg)
Balázs Kis
Co-Founder & Co-CEO at memoQ