Content vs Information

Posted In Tech Writing - By Sudipa Sarkar On Monday, November 17th, 2008 With 0 Comments






Pin It


A thin line between exists these two terms which many a times results in confusion of what we perceive – mere content or valuable information from the piles of content.

The word “Content” has many definitions such as “something that is to be expressed through some medium, as speech, writing, or any of various arts” or “substantive information or creative material”.

Whereas “Information” can be termed as “knowledge communicated or received concerning a particular fact or circumstance” or “knowledge gained through study, communication, research, instruction”.

It can be said that content is a field where knowledge matures in a shape of information. Content is important because it provides the knowledge, and information adds flavor to it.

For example in case of functional specification, customer requirements is translated into detailed analysis in the functional specification covering Requirement Background, Scope, Assumptions, Limitation, Exclusions, Implementations, Terminology and so on. The whole document not only approaches the requirement from the technical point of view, but also supplies ancillary functionalities and attempts to portray a “big picture”.

This “big picture” often creates trouble for technical writer when he tries to document the enhancement. Sometimes, it is a challenge to cover each important element and not to leave out any important information. Sometimes the specification document elaborates few elements so widely that it creates more confusion for those who never participated either as a developer or tester.

To overcome this problem, one can follow many proven steps. Few of them are quite generic yet effective and can be implemented at any point of time, such as:

Discuss with the business or technical analyst to get hands-on knowledge on the enhancement. In many cases, when approached, it has been found that the specification document itself is either not updated or quite ambiguous. So, it is their duty to either release the document with version or update the master document before releasing it.



Participate in the demo showcasing or online product training that might help to understand the interface better although people showing the demo always have a tendency to perform it quite superficially and avoid any complex issues.

It is sometimes imperative to play with the application and understand the functionality from the user’s or administrator’s point of view. While documenting writers tend to justify what they are writing is enough and appropriate. Manipulating the interface with the help of his writing validates how effectively he has illustrated the functionality. Test plans and acceptance criteria can both come handy in this scenario.

So, in a nutshell, a writer can either follow task based approach or feature based approach to extract required information step-by-step and present a clear, concise, and organized documentation to the end user.

-Sudipa Sarkar