In a recent casual coffee-table conversation in our office, one of my colleagues asked this question to the tech-writing group. And, none of us had satisfactory answers. That’s because each of our reader has a unique, different level of knowledge. In fact, even the tech-writing team members in my office do not have the same level of knowledge about the company’s products. So, how do we determine the “technicality” in our
Last month, I got a chance to read from some of my old books. I am a marketing graduate. So, while I read some random pages from the marketing domain, I could see that the learning matched to technical communication as well. But, how could the lessons on branding teach anything about technical communication? In this post, I try to explore this question to help improve my understanding.
This post is about progressive reduction, which is what I’ve recently read about. From what I have gleaned, progressive reduction is about those gradual changes (mostly reduction) in the UI elements that relate to your time-lapsed incremental cognition of a product. In other words, progressive reduction is in continuously adapting the UI elements of your product based on the gradual improvement in its usability. Read the full post.
The bent towards information design is on account of its applicability – A picture, as they say, is worth a thousand words. The use of graphics minimizes the use of content. Rather, it squeezes the underlying message of the content into a graphics. Despite the usually observed bent of mind, I believe that the key elements of Information Design and Technical Communication are the same. Here’s how…
Redundancy is inseparable. But, it is still important to make mutual sense. Your reader wants to search for content that resolves the purpose of the search. But, that sadly isn’t always on our list of goals. This article tries to see the possible definition and cause of redundancy, and suggest the probable solutions to resolve or avoid it. Click here to read the full article. Note: The stub contains the
This article focuses on the use of uniform writing structure and tone in order to improve comprehension and promote correct action. The thought of writing this post came to me as I searched through the pages of the legacy documentation for one of our products. I think the idea of maintaining a uniform structure is important, yet (often) ignored. Read the full post here. Note: The stub contains the link
I often say this to myself: Anyone can write, but everyone cannot become a writer. But, when we can (and do) learn to write, why can’t we learn to become writers? Language is a skill, which can be learned and mastered over a period of time. We must learn to follow the rules. Although subconsciously, notice that we almost always associate “writing” with “ability.” But, if that is true, why
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