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 anything. So, if it is poem, I am like “Uh!” and if it is a story, I’m like “So?” Write-ups that do not take either me or my learning from, for example, point A to point B are bad write-ups for me. I do not read poems. Not from all the writers. I am choosy, because not all writers do justice to their works. But, here’s one who I read quite often, and every time I see a new poem, I realize the poet wants me to step into her shoes and flow through the story she narrates.
But then there are those writers, who can beautify their words, and still fail to get the messages across. In contrast, I would love to read those writers who can break the ice, tell me a story, and make me smell the flowers as I read through their texts – just like the Juhi’s poems I just shared with you. Such writers, I believe, are a lot more effective. That’s because they have a message for me. Beautification is not a message. Beautification may be important, but not for me.
My take? Fiction, non-fiction, biographies, and poems: I see that the quality of write-ups (good or bad) depends on the flow of thoughts from the intentions to the messages. This flow is what can help us connect those pesky little dots. The message in the flow is about something that I either need to know or am interested to know about. And, as long as the writer can help usher me through the tides of the emotions, and still communicate the message and bring me (or my learning) from point A to point B, I’m good.
Plain, simple rules, aren’t they? Flow and message! But, why am I writing this to you? Why? Or, is it not something you already know? How many of us not write to rant out our pain? How many of us write for the fun and soul in writing? I am not sure. Not sure, because I know that writing isn’t always for a purpose. Not sure, because we know that we know the principles or the idea, and yet not follow it. Most of us don’t. But, I think I do. Do you?
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 phones” versus searching purposefully for “new Android phones under 10,000.” The analogy lends us some interesting insights that can help us communication information effectively. Let’s explore.
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.
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.
The easiest way to begin the conversation is to see what demarcate buyers and users.
It is strategic to choose which side you represent as a technical communicator. At large, all of us fall on the same side of the table – the sellers. We obviously don’t “sell” our content, but we do contribute (both actively and passively) to the sales cycle. Deep down, however, we aim to write from the point of view of the buyers and users. Note that I am using an “AND” between buyers and users.
I prepare and release technical documentation, just as any of you do. And, like you do, I too focus on what my company’s products deliver. But, the basic concepts of Business Economics help me demarcate the buyers and the users.
The same demarcation that applies to Customers and Consumers, applies to buyers and users as well. Consider the following introductions to customers and consumers, based on what I have gleaned from the subject:
Customers. They may or may not use the product (and hence may not always qualify as end users), but they are the ones who buy. They implement a purchase decision. They influence the purchaser, and hence the purchase decision. They do not consume the products but can use the services and hence can impact your communications. The brand-level changes affect their perceptions.
Consumers. They use the product but are not necessarily the ones who buy. They either feel or create a need to purchase. Therefore, they are the ones who create and govern the purchase decisions, but under the influence of the buyers. They consume products and avail services. The feature-level changes affect them. They mostly know what they need.
The points mentioned above are generic, but they communicate the scenario effectively. Let us now take an example to further outline the comparison of behaviors. Pick, for example, a health drink for children; Let me define it as “NutraChamp.” As customers (or buyers, in this case), you are affected by the brand philosophy (or value proposition) of the product.
But, the fact that the product is available in the flavor of your choice, which is a feature-level change, will affect you only if you are the consumer (or the user) of the product. The choice to go for a particular flavor, or even color of the packaging will belong to the consumer, but the decision to finally purchase it will still belong to the customer. And, in all probabilities, the purchase decision will not be governed by the color of the packaging and the flavor, but the information supplied with the product. This is where documentation plays its part in the sales cycle.
The information supplied – in this case, the supplements fact sheet – plays a strategic role when purchasing a product. For technical communicators like us, it is therefore important to understand the buying behaviors to communicate only what contributes to the learning curve of our customers as well as consumers and hence affects their purchase behaviors.
In similar situations, I focus on providing what my customers need. Additionally, my documentation becomes more “sellable” if I also include what they want. My learning, from the Business Economics class, has paid off! Need is extremely important, and hence, in our example, if the NutraChamp health drink contains a combination of health benefits, taste, and flavor, both the buyers as well as the users will be happy and satisfied with the purchase decision.
As a marketer, I might think differently, but as a technical communicator, I will try to communicate the health benefits, by providing the supplements fact sheet, and miscellaneous documentation, if needed.
I understand that as a technical communicator, I do not write in the marketing terminology. So, the purpose of this post is not to tell you to package and present wants as needs to buyers and users. But, based on our interaction so far, it is not difficult to assume that our documentation should contain feature-centric, benefit-oriented information.
I do not intend to tell you to make documents more “sellable”, but when the documents should address the needs as well as wants, the points mentioned above can come in handy.