Although many organisations see user assistance as a “good thing”, it’s not immune to the belt tightening that many organisations face in times of difficulty.
Business expert Mike Southon recommends that in recessionary times, organisations should focus on getting sales from existing customers – so customer retention becomes ever more important.
There’s a virtuous circle of a customer finding user assistance helps them and becoming a loyal and happy customer. Whilst user documentation can help with the perceived quality of a product before the sale, its key value is in keeping customers: customer retention in marketing-speak. It’s the philosophy of Toyota and others – the focus on quality and customer service.
Chris Bose of In Press PR Ltd, told me that recessions are the times when market share changes. This is why successful companies reduce their advertising spend, but never cancel it. They know that when the economy turns and business improves, they’ll get more sales than the competition – more sales than they ever did before, most likely.
Recessions are also often the times of greatest technological change. The Great Depression saw the wide-scale introduction on electricity to houses in Britain, and, today, we’re seeing significant developments in Help Authoring software. Those companies that can adopt these new developments in user assistance now will be able to differentiate themselves from their competitors – something of importance in these highly competitive times. As the economy swings upwards, this competitive edge will make a difference in sales.
However, it can very hard to measure the effectiveness of documentation. Again, this is where recent technological changes come into the place. A number of Help tools now enable you to measure how many people accessed your documentation, whether it assisted them or not, as well as many other useful measures. Indeed, Web based user documentation can be the trick to increasing your Search Engine rankings (but keep that a secret!).
It may be that you can provide better user assistance for less money. You may find you save on translation costs, lower support calls and lower printing costs.
Perhaps the question should not be “why bother?”, but “how can we do it better?”
In response to your question "why bother…." verus "How can we do it better". We have found that well designed electronic guides (documentation) combined with e-mailed care & maintenance reminders are viewed as valuable product benefit to the buyer.
But the most important benefits go to the suppliers that provide the electronic guides and e-mail reminders. They get a more satisfied buyer who refer families and friends. Best of all these interactions can be tracked to prove the value of these services.
I am not saying abandon documentation, but there is this. Once, long ago, TV talk show host, Author, and musician Steve Allen, (with number one hit records to his name), couldn’t manage to land a job as piano player for the Tonight Show orchestra. Why? Because he never learned how to read music. With a daily TV show broadcasting every night, it can be well imagined why being able to sight read music was a necessity. Changing performers every night meant short rehearsal time. To keep up, each orchestra member had to be able to read music. The object lesson is, fundamentally, if you can’t read the code and understand it in the first place, no amount of documentation will allow you to truly understand the process. Documentation helps significantly, but remember documentation is outdated the minute it is written. Trust what you see in the code first, then let documentation do its part.
As someone who has written a fair share of documentation, including computer users’ guides, I think the real problem isn’t with the end user’s knowledge, it’s with the assumptions most documentation starts with.
1) People know more than they really do.
As an instructional video producer for medical school students, I learned that people can only grasp so much information per viewing (i.e., if you have 0 knowledge going in, the most you can learn is a “C” grade. But if you watch the program a few more times, your knowledge base — and the new information you take in — increases as well.
Therefore, documentation needs to take ALL learner skill levels into account. I write documentation to meet the needs of all users by creating the content in 3 “columns” for 3 different audience segments — those with no knowledge, those with some, and those who just want a “quick reference” to the task at hand.
2) People with the most product knowledge should write the documentation.
Actually, just the opposite should be the rule. Many computer manuals/help pages were (are?) written by the people who designed/built the project, in a stream-of-consciousness style, based on whatever they thought was relevant in the order they thought of it. I can remember my Apple 2e came with 3 huge manuals, none of which said, “Start here.” So 3 of us each took a book and tried to figure out what to do after we plugged everything together. Granted times have much improved, but the reason I was hired by Commodore, for the 64, was that I would be the “dumbest user” they could find. That has always been a key to all other documentation projects I’ve handled since. You don’t have to be the “dumbest” but you have to put yourself in the place of the no-nothing user. I ask every question I can think of. I’ve even found software lock-ups for clients because I pretended my cat just walked across the keyboard.
3) People all learn the same way.
This is obviously not true, but it’s amazing to me how few ways there are to find what I’m looking for in a “help” section. When people ask me to help them with help, I have to think like the “tech” who wrote the help. Users shouldn’t have to do this. Just when you’ve thought you’ve asked all the ways people would think of to look up a particular question, you need to have some outsider ask you to find something. More often than not their “keywords” would lead you down a whole ‘nother way of looking at things. Some folks learn best with pictures, some with words, some with movement, some by touch. Today’s documentation should take all these learners into account.
4) We all speak the same language.
Anyone who’s tried to decipher instructions that were a direct translation into your language from someone else’s raise your hand. There are whole web sites devoted to these malaprops. Put yourself in the place of someone whose second language is not yours and you’ll find that you too need choose your terms for simple translation and structure.
5) It’s logical to everyone who’s reviewed the content, so we can skip testing.
The next time you have what you think is a finished product, give it to the end user, the receptionist, and anyone else you can think of. Even if they can’t figure out the details of the content, they sure can tell you what isn’t clear, easy-to-follow, and well written.
Maybe nobody “reads” documentation, because documentation should NOT have to be “read.” It should be, as most documentation synonyms imply — a user’s GUIDE. A way to successfully navigate through uncharted territory, with someone who is looking out for the USER’S experience.
Thanks for letting me share.
Bernard – well said!
As another ‘dumbest’ user I couldn’t agree more! I know you can’t avoid picking up SOME knowledge of a product as you write about it, but it is important to remember that you’re writing a guide for someone who may know nothing at all. I think it’s also important to remeber that people don’t start at the beginning and read to the end, so the guide should be understandable wheever you start, and NOT assume that you’ve already found out how to, say, get to the screen you’re just about to describe. And don’t be afraid to cross-refer! It’s so useful – look at Wikipedia, it’s all cross-references.