During a recent online conversation, someone requested for a list of questions I would typically ask to a subject matter expert (SME) to prepare technical documentation for a topic. Of course, the parameters may vary, but there is still a list of questions that apply across all sizes or complexities of projects. In this post, I share with you the list of questions that I shared with them…
“For god sake, once, just once, connect those pesky dots. Can’t you see that I can’t understand anything? Even a word?” That’s what I often say when I look at bad write-ups. I just can’t connect those pesky dots to see what the story is. But, am I the only one who rubbishes write-ups that often? Don’t you too? I think a write-up is bad because it doesn’t tell me
Information communication is a cyclical process, much like the usual purchase decisions that you take. So, if we can wear the shoes of our users and understand their requirements, we can write better documents or even project the information-communication more effectively. In this blog post, I try to find those effective checkpoints using the purchase-decision analogy. We will take daily-life examples, such as using mobile applications to searching for “mobile
Heuristics, unlike what most of us know, is not ONLY about the trial-and-error way of doing things. Heuristics are those basic guidelines that mostly cover the generic application of common sense. And, I don’t see a better faculty than technical communication to apply this technique. Here’s what I have to share.
There are a lot of things that drive our searches. Therefore, it is true that we often search for things that we don’t know. Or that we begin searching for one thing and end up finding another. And, such information is not a goal, but a by-product. But wait; there is lot more to this story. Come, see for yourself.
Premise In the regular classes on Business Economics, during my graduation, I learned about certain concepts that still apply. Two of such concepts, Buyers and Users, are applicable in technical communication to a great extent. Can those concepts lend any insights to us? Do we prepare our documentation considering the buyers or users? Or, do we concentrate on merely describing the features? The discussion follows in this post. Observation The