The client asked me to develop a help file for a software application. I asked who the target audience was. How technically versed were they with the application? What did they expect in documentation? I never got a good answer.
While I found the software relatively easy to use, it did have some complexity. I thought the users should be aware of these “power user” functions, and wrote the help file accordingly.
When I presented it, I got a two-word reply. “Too verbose.” A bit surprised, I asked the client what he meant. Could he elaborate? No – it just had too many words.
Back at my desk, I thought about it. I eliminated sentences and chopped up many others. I probably reduced the information by a good 25%. And upon presenting it, I got the same two-word reply: “Too verbose.” No explanation. No guidance.
So I went back to revise it again. I removed all adjectives, adverbs, and all instances of passive text. The document didn’t seem very useful to me, but when my client looked at it, he smiled. And he then gave a one-word reply: perfect.
I later learned that the company had for-pay technical support. If you couldn’t figure things out on your own, you had to pay for support. This is a legitimate way that many companies operate, and I have no problem writing such documentation if that is what a client needs.
When I write your documentation – you are my client. But I do not read minds. In the above example, it would have been very helpful to know that I was being asked to provide minimalist documentation because the business objective was to make Technical Support department a profit center. Once I align with the business objective, writing the desired documentation becomes much more straightforward.
Thoughts? Questions? Comment below and I’ll respond.
– Bal
No Comments