Commonly Asked Technical Writing Related Questions

Is technical writing different from creative writing?

Technical writing is definitely different from creative writing. It is not for any reader—it is directed to a specific audience who reads to understand a product. So, the writing should be clear, concise, accurate, and easy to understand.

Writers like Shoba De, Chetan Bhagat, Jeffery archer, and Robin Cook write to satisfy their creative urge. Technical writers have to follow rules and guidelines regarding what to write and what not to write.

Technical writing is format driven. Companies and technical journals often have their own way of organizing and laying out the content of technical documents. The writers have to follow the organization specific format and style. In short, we can say that the characteristics that set technical writing apart from other types of writing include audience, language, purpose, format, writing style, and the use of visuals.

Is it necessary for the technical writers to have technical background?

NO! It is not necessary unless the subject you are going to write about is highly technical in nature and requires a long learning curve even to understand the basic concepts. In such cases, it is advantageous for you to have technical background, but not in the same sense as the engineers, the programmers, the developers, or the support staff.

Apart from taking care of the format, language, and style, technical writers should also understand the technology, theory, and applications of the projects they are assigned to document. To do that, writers either need some technical expertise or have the ability to understand the information/technology.

The idea is to be able to understand the function, feature, and/or product well enough to write about them, but at the same time be able to view them from the standpoint of an ignorant user who doesn’t know the product well. A good technical writer should be able to ask the questions that a user might have and write the manual accordingly.

Programmers, developers, engineers and/or project managers are often too close to the subject and the product they develop that they don’t think the obvious! Hence being able to look at a function, a feature, a product from the standpoint of an user can also be an asset.

Is good writing skill the only qualification needed for a technical writer?

No! Good writing skill is a definite prerequisite. But again, there are many types of writers. Some are verbose and some others may use flowery and creative language. Such writers are definitely not well-suited for technical writing. But, if they learn to write in a restricted manner, they make excellent technical writers.

As a technical writer, you must be a clear thinker, well-organized, follow styles and formats, and adapt to restrictive writing. You should also be a quick learner, good researcher, and extremely good at multitasking. The list of skills is endless.

Is there a need to have formal training in English?

No! I am not aware how the knowledge of the works of Shakespeare, Keats, and/or Frost can help you with technical writing. Jokes apart, it is important that you have sound knowledge of the language. Formal training in English is definitely not a prerequisite, but it is an advantage in some cases. In India, unlike other areas (web development, web designing, programming, graphics designing, animation, quality assurance), technical writing does not have a widely recognized certification.

The educational qualification required, is also inconsistent and wholly depends on the requirement of the job and the organization. Hence, it is important for the technical writers to have a right balance of the language skills and understanding of the technical concepts.

Which is more important—writing skills or subject/domain knowledge?

What is more important—your right leg or your left leg? Both are equally important. You may be little more comfortable using one over the other. The same stand is applicable to writing skills and subject/domain knowledge.

The written skills gets you the job, where as you can learn the subject on the job. But unless and until you know the subject you have to write about, you can’t do a good job. Apart from the other skills (grammar, writing, critical thinking, etc.) domain knowledge is also important for succeeding as a technical writer.

Good audience analysis includes knowing about your users and their requirements. It includes learning about the domain you work in, be it engineering, finance, medicine, law, gardening, database maintenance, or rocket science.

Can technical writers do the job of an editor?

Writers with eye for detail and good editing and organizational skills can double up as editors. In large and well-established documentation groups, editing is definitely an editors job. Not all technical writers can do justice to the job of an editor. The ability of being an editor depends wholly on the editorial skills of the writers, not on the years of experience they command.

Will previous experience in another field be taken into account when changing jobs to technical writing?

A commonly asked question is: I have n years experience in xyz field. Why do I have to join as a trainee or as a junior writer? Simple!

It is because you will be learning the basics of the job just as the others. The same amount of time and effort will have to be dedicated to you for training (the concepts, writing styles, procedures, tools, etc.). This is even more evident if the work experience you have is in no way related to technical writing.

Any previous experience will be valid in terms of the soft skills (team spirit, communication, leadership qualities, attitude towards work, etc.) which will help you to get faster promotions if you are a good technical writer. Use the non-related work experience for climbing up the professional ladder, not to be close to the top of the ladder when you enter the profession.

In a senior position, you are expected to make important decisions about the project, which can make or break a project. Relevant experience helps in making the right decision at critical stages of the project. Making wrong decisions, when you consciously think that you are right may cause a critical situation!

If you strongly feel that the prior experience is of extreme importance to you, you should probably continue in the same field. If you have decided to change careers and move on from your present field to become a technical writer, then let go of the ghost of the “previous experience” and think of yourself as a technical writer. This will help you move forward with a clarity of thought.

Is age a barrier?

It is and it is not! When hiring experienced writers, age is definitely not considered. When hiring someone without previous technical writing experience, age sometimes becomes a selection criteria. One of the reason is because, after other experience, the expectations of the candidate is much more than a fresher who is relatively younger and inexperienced.

Most of the times, organizations are ready to take in people with no related experience in junior positions offering salary relative to their relevant experience and skills. Those seeking a job may not be able to accept the fact that after having years of work experience, they are considered to be on the same level as the trainees.

In such a situation, ask yourself if you possess the skills required for this job? Do you have the relevant experience? Why should the organization pay you for the skills and the experience you don’t possess? This will give you an answer why you are recruited at an entry level.

You need to be flexible and mature in terms of understanding and accepting your limitations. If you are comfortable working with youngsters, in a junior position, for a lesser salary (probably), and if you are confident of using the skills of your prior working experience(s) to your advantage, age doesn’t really matter.

On a personal perspective, the age limit is more of a mental state than physical. If you are eager to learn and grow in the team starting from the basics, age is not a constraint. For that matter, age is not a barrier in any field if you have the right attitude and if you are mentally and physically fit for the job/work.

Advertisements

Self Editing Tips

This article will help you when editing your own work. Most of these tips are equally relevant when peer editing.

  • Before you start editing ask yourself when, where, why, and how the document will be used.
  • Even if you prefer editing online, take a printout of the document when you are doing the final edit. You may miss certain things as you edit online.
  • Editing requires extreme focus and concentration. So perform edits when you are not pressed of time or have no deadlines to attend to. The best time to edit any document is when you start your working day in the morning. You are back to work after a break and it helps you see the matter with a fresh mind and perspective.
  • Edit in small doses. The longer you edit without a break, the less effective you will become. Divide big projects into sections you can edit completely without tiring your mind.
  • Don’t try to find everything at once. Skim for some things (such as fonts, spacing, missing illustrations). Then, go back to check out some other thing. That is, do a few rounds of edits, each focusing on a particular type.
  • If the document is too complex, read the draft several times. First, read the content to check the user level and general organization of the information at. Later look again for other problems such as clarity of language and other intricate details.
  • Add to your checklist any common errors you know you make and anything you feel needs to be checked or verified for that particular document.
  • Use a style sheet and a checklist as you edit. Keep them handy and refer to them when required.
  • Don’t overlook the obvious. Pay attention to the document title, document number, version number, and chapter or section titles, page numbering, and so on.
  • If you have used materials from another document or chapter, check that any required changes (such as the product name) have been made.
  • Check the line breaks and page breaks. Transitions to the next line or to the next page are common problem areas.
  • Look for symbols that come in pairs—parentheses, brackets, and quotation marks.
  • Double or triple-check equations. Check calculations.
  • Avoid language-edits at the same time as you perform substantive editing. It slows you down and will also distract you.

Spare some time to write a summary of your thoughts, observations, impressions, criticisms, or feelings about the draft. Categorize your comments according to the type of problem or error.

Advantages of Planning a Project

Planning the documentation project helps you in the following ways:

Reaching an Agreement

  • You can consider all the aspects of the documentation efforts when you plan it. You can think over the project and make all the decisions up front, rather than as you write. So you have all the agreement on the approach to document setup before you start writing.
  • If the project involves more than one writer, you can get an agreement from them regarding their responsibilities on what you intend to do, so that all are clear about their part in the project. Difference in views can be taken care of in the initial stages of the documentation effort.

Formalizing Certain Aspects

Planning helps in formalizing the following components:
• Project goals and objectives.
• Scope and expectations of the document.
• Roles and responsibilities of the team members.
• Assumptions and constraints.
• Quality management approach.
• Project management approach.
• Ground rules for the project (anything that is different than usual).

These can be grouped into separate topics in the documentation project plan.

Uncovering Problems

For large documentation project, as you start planning it in detail, you will uncover the problems before you start writing the document.

  • The plan will help answer questions regarding what goes into the manual, where it is to be added, the style to be used, etc.
  • You can avoid doing/redoing some tasks if you anticipate certain problems at the starting of the project.
  • It saves hours of rework or delay which germinates from unclear goals and missing information.
  • You have time to look for and decide alternate course of actions.
  • You can plan some buffer time for solving problems, right at the planning stage.

Importance of Project Plan

Planning is the most important aspect of a documentation project. A good plan provides a basis for every action that needs to be performed. It helps you frame the projects so that you can work towards a goal. It is very unfortunate that in most organizations, documentation planning is usually regarded as something to be done after the development phase is complete.

Careful analysis and planning are integral parts of the working life of a technical writer. You cannot have quality in a project which is not properly defined and/or planned. You need a predefined structure to produce quality documents in a predictable and reliable manner. Though the basic approach may remain the same, the planning process may vary for organization to organization. To produce an useful documentation, consider it to be an integral part of the product development phase.

The trouble with plans is that they are based on the way things are now. To be successful, your plan must focus on what you want, not what you have. —Nido Qubein

Very often, projects change so much that you diverge from the original plan as youprogress. So, planning at an initial stage may sometimes seem to be a waste of time,but no one can deny that it works as a road map that points to a destination. You canalways change it as you develop the document.

  • As soon as you get a project in hand, the temptation is to start writing. Starting immediately is the worst thing to do because you are more likely to hit the writers block and wonder what to write and how to write. In the process, you will end up with a poorly written document.
  • Sometimes, the project may get into such slippery grounds that you are not sure about what is happening and what is to be done. In such confusion, you can refer to the plan and get right back on the track.
  • The plan enables various people in a project to agree upon the contents, design, and other such details of the project before starting the documentation efforts. The product and documentation managers agree and approve of the way you intend to handle the documentation.
  • The plan is a formal agreement between the project manager, documentation manager, writers, and reviewers regarding the dates, formats, and other issues. Create the plan and get it reviewed and approved by the people involved in the project. This way, the management is aware of the effort that will go into creating the document and you will also have their agreement on certain aspects of the project.

Importance of Domain Knowledge

An ongoing debatable question is, do technical writers need domain knowledge? OR What is more important—writing skills or subject/domain knowledge?

What is more important—your right hand or your left hand? If I am not mistaken, both are equally important. You may be a little more comfortable using one over the other. The same stand is applicable to writing skills and subject/domain knowledge. The writing skills get you the job, whereas you learn the subject on the job. Good audience analysis includes knowing about your users and their requirements. So, apart from the primary competencies (language skills, knowledge of tools, grammar, writing skills, critical thinking, etc.) domain knowledge is also important for succeeding as a technical writer.

So it is important for you to learn about the domain you work in, be it engineering, finance, medicine, law, gardening, database maintenance, or rocket science. You can’t do a good job if:

  • You have excellent language and writing skills, but don’t know the subject you have to write about.
  • You are a technical expert, but lack in language and writing skills.

A few years back, technical writers were seen as language experts. Now, many organizations advertise for writers with a technical background. This is because people have now realized that technical writers are not just linguistic experts. They perform a lot more activities and tasks—writers also have to understand the concepts, theories, ideas, designs, and code to effectively communicate them.

Having subject matter knowledge can mean:

  • Having sufficient knowledge of the subject to effectively communicate about it.

What is more important than knowledge of a technical subject is the ability to understand the subject and write about it. To write different types of documents you require a different level of understanding of the domain/subject. You should have the ability to understand the subject (software, engineering, accounts, inventory, law, medicine, science, health, business, etc.) and express it in writing. You can be an effective communicator only if you understand and know about what you want to communicate.

Example: If you have to write about electronic products, it would be extremely helpful if you have an electronics background. It is not necessary but is surely helpful to you as it saves time and effort required for training, understanding the concepts, and reviewing the documents.

You don’t need to master the technology, but you should be a fast learner.

  • Having the critical analysis skills to comprehend and understand complex, technical, and scientific concepts. For instance, a technical writer should:
    • Know about the subject, not the code to write GUI related information of the product and/or software.
    • Have a basic knowledge about the code to write for advanced users.
    • Know something about the equipment to write the installation procedures.
    • Know everything about aviation and the working of the aircraft to write an operations guide for an airplane.

Writing different types of documents for different industries requires a different level of understanding of the domain/subject.

  • Understanding the technology just enough to confidently explain the technology.

Even if you don’t have the relevant background, it is very important to be able to understand the basic concepts of the technology, irrespective of the subject. It will help you describe complex technology clearly and concisely. As a writer, you do not need the knowledge required to design and build the product. If you have some knowledge about the topic you have to write about, you can learn the new product faster and write about it better.

Example: You must have come across sales people in automobile and electronic showrooms. They know just enough about the products they deal with, to give the precise information to impress the prospective customer. They talk about a model (television, microwave, automobile, etc.) and then move on to demonstrate the features of the next model. They can give a good comparison about the features and the cost of various models of the product they are trying to sell.

Technical writers should neither know more nor less. This is almost like adding the right amount to spice and salt to a dish.

As a technical writer, you write about technologies which already exist and products that are already created! So, you need not possess an in-depth knowledge about the subjects, but you should definitely have to be a fast learner and also need to have some amount of interest in the subject you write about. In short, the interest in learning new technologies, the ability to grasp and understand the concepts quickly, and the ability to explaining technical concepts to the users is what you need!

These days, many organizations want writers with strong technical skills. You may have come across advertisements for writers with specific background—finance, instrumentation, pharmacy, aeronautics, electronics, etc. to write about their product. There is also a requirement for writers who can read and interpret Java, Visual Basic, or C++ code.

Knowing the tools and having excellent writing skills will help you in this regard. In some technical writing positions, having technical qualification and competence is an important success factor as it will help you in the following ways:

  • Planning better: It will help you plan your project in a better and effective manner.
    • You can easily identify areas that need to be documented in different types of documents (user’s guide, functional specification, systems requirements document, installation guide, etc.).
    • You can understand the importance and the implications of the functionalities. This makes it easier to create the content accordingly.
    • You can prioritize tasks based on these inputs.
  • Conversing intelligently: Having good knowledge about the subject helps you to intelligently converse with engineers on complex software (database, communication, network engineering concepts, to name a few).
  • Organizing: It will help you organize large quantities of technical material in a better and efficient manner.
  • Saving time: Knowing the technical concepts saves time as:
    • You do not have to spend a lot of time researching, reading, and understanding the product/technology.
    • The SME’s do not have to explain to you the basic concepts of the technology.
  • Reasoning skills: It is but true that physics, chemistry, mathematics, and computer graduates (apart from engineering) have better reasoning skills than the social sciences and arts graduates. It has nothing to do with intelligence. It is all about training the mind to think in a specific manner.

Let me wind up saying that the emphasis of technical writing is in the field of software which happens to be the largest segment of the technical writing market (at least in India). Your knowledge can be in other areas, such as engineering, medicine, manufacturing, finance, and law. This is not an important criterion, but it definitely gives you an edge over the others and the opportunity to get into the related field.

Job Hopping (in Technical Writing): A Concern

One of the major concerns of today, not restricted to the technical writing community, is job hopping. It does not give a good picture to the remote/parent companies who have set up documentation (or other teams) in India. On an average, it takes a writer at least a year to get adjusted in an organization, to understand the basic documentation specific requirements of the organization (guidelines, tools, styles, process, etc), and understand the products.

By the time the writers understand the work process, procedure, and start performing on their own, they feel that it is time to move on! This attitude of the employees is very weird, immature, and annoying. Most of the time the reasons cited by the writers for skipping and hopping out of the companies are:

  • Want to write new documents
  • Not a challenging job
  • Designation
  • Promotion
  • Better salary
  • Other reasons
  1. Want to Write New Documents

When the writers cite the reason as wanting to write new documents, the managers are tempted to say, \But you can’t even update an existing document properly, how do you think you can create a new one? By the time the write is capable of taking such responsibilities, and the manager or the team leader plans to allocate responsible projects, the writers decide to leave.

In Reality

All the writers, however, experienced they are, have their share of work in updating documentation. Writers get newer documents to write only if new products are launched by the organization or when the existing product changes drastically. The writers who are interested in writing only about new products, should either work as freelancers or join a documentation company because in both the cases, they get to work with different clients on varied projects and subjects.

  1. Not a Challenging Job

Many writers complain that they don’t get challenging work to do. Ask them what they want to do and you will realize that most of them don’t even know that they mean by the term challenging or what type of challenging work they want to work on.

In Reality

There are so many tasks that the writers do to make the job interesting and challenging. No one will hand challenging work on a golden platter. First and foremost the technical writers should analyze themselves:

    1. Rate themselves as writers.
      1. Check if they have shown interest in doing challenging or responsible kind of work.
      2. Check if they are capable of doing the tasks they are interested in.
      3. Check what they have done to make the work challenging
    2. They have to check if they have tried to do the following:
      1. Gather customer feedback to understand if the documentation is useful to them.
      2. Improvise the existing documentation by performing usability testing?
      3. Perform GUI reviews and give inputs to the development team?
      4. Work with the marketing, sales, marketing, or human resource in creating brochures, internal newsletter, etc.
      5. Have they remotely tried to do any of these? If not, what challenges are they looking for?
  1. Designation

You will find writers with one or two years experience wanting to have the designation of senior writers. I have come across varied expectations of the writers. Some make sense while some are just plain ridiculous. A writer with just five months into this field (and no formal training in technical communication) was reluctant to join as a trainee because according to her, she had 5 months experience. I could not figure out how that experience which was tool focused would help her perform the activities in my team. Also, she was on the lookout for a “better job” with “more responsibilities”, and a “better salary” in 5 months time after joining an organization. I recruited a fresher instead.

A proofreader with barely three years experience wanted a managerial position because according to him, he was already leading team though his designation was “proofreader”. He had absolutely no idea about the tools used or the documentation development life cycle (DDLC), and the basic concept of technical writing. All he knew were the terms technical review and proofreading. According to him, proofreading was an authoritative job profile because he had to sign off the documentation effort. So he felt that he was actually leading the team of writers though in reality, he was not.

In Reality

The IT companies should ensure that there is a certain level of consistency in designations. Human resources managers should ensure that a given designation should not lose its value. It should be tied to appropriate skills, experience, and responsibilities. It is ridiculous to offer the designation of Senior Writer after one year experience or that of a Team Leader after two years of experience.

  1.  Promotion

Kissa kursi ka has been an age-old story. There has been a fascination and temptation for the mighty chair right from the time of Alexander the Great till date. In the work scenario, it is in the form of promotions. A writer with two years experience wants to become a senior writer. Those with 3-4 years experience want to be the team lead. There may be one in thousands who have the capability to take up the responsibilities and have such fast promotions, but that does not mean that all can.

If the question is, “If XYZ can become a team leader, why can’t I? The answer should be short, yet loud and clear, “XYZ has displayed the skills, expertise, and qualities required for a team leader.”

In Reality

After 2-3 years experience, writers move out in search of better pastures, wanting a better hike in salary and a bigger designation. Their two years of experience actually has more value in their current organization because they already know the product and now, they are in a position to take up more responsibilities.

After 4-5 years, in an organization, they would have mastered most of the requirements of the trade, taken up responsible tasks, and handled tricky projects. Moving out for better pastures at that stage may make sense.

  1. Better Salary

If you spend time with people who are ready to hop out and talk to them, you will find that most of the reasons they give are usually not valid. They leave because they probably get a significant raise in salary in the other organization. During the interviews, many writers demand a huge sum because according to them, that is the market value of a writer. Salary seems to be the major fixation for 80% of the writers, especially those who get into the field for the heck of it.

In Reality

The market figure could be true, but the writers should also take a stock of themselves. They have to figure out if they are good writers capable of writing a few pages that don’t require an edit or are they solely depending on the number years of experience and the tool knowledge to demand their worth. Their worth and expectations should match with the actual skill sets expected from a writer of their experience.

  1. Other Reasons

Some of the valid reasons why employees may want to move on are:

    • A mismatch between personal ambitions and the company’s mission (or vision). This can be avoided to a certain extent if the screening and selection process is good enough. The candidates hired for a particular project /assignment has to be informed about the exact responsibilities they will be handling.
    • Lack of motivation—the company is not able to identify and utilize the strengths of the candidate (or vice versa).
    • Lack of opportunities—learning, training, growth, responsibilities, etc.
    • Lack of clarity in terms of future plans, growth, and ambitions.
    • Organizational culture.

Recommendation

These are something you can do to overcome the job hopping related problems.

  • Hire freshers: From a business point of view, unless and until it is absolutely necessary, is it better to hire freshers, train them, and mold them to your needs. It is better than recruiting technical writers with 6 months to 2 years of experience who demand 40-60% hike on their current CTC (cost to company). About 80% of such writers are not even worth to be paid half of what they demand.
  • Weed out non-writers: During the interview stage filter out non-writers. Many times the applicants are those who have failed to get into the world of programming and development. They view technical writing as an easy entry into the organization or land up with a job until they get what they are looking for.
  • Money is not everything: We all work for money. Don’t say that you don’t,  but there are other things apart from money that should be the primary focus. Ensure that you hire writers who display professional behavior and work ethics. Else, Indian technical communicators will loose reliability and chances are that the organizations that are ready to invest in India may not be ready to do so in the near future.
  • Look for the right attitude: Candidates should be made to understand that they should have the right skills, attitude, passion, and productivity at work. The money will follow. They are compensated for doing quality work and delivering the project on time in terms of salary. How well they do it and the other responsibilities they take up become the deciding factor for their appraisal.
  • Consistent designation: The IT companies should ensure that the designations are consistent. Certain aspects like work profile, level of experience, responsibilities, skills, and maturity, should be attached to each designation. By giving a designation of the team leader to a person with 2-3 years experience, we are responsible for raising their expectations.
  • Hire the right person: Hiring managers should be aware that filling up a position is important, but getting the right person with the right skills for the right remuneration is equally important. We all know that the biggest enemy of any hiring manager is another hiring manager who is ready to offer a bigger pay packet, higher position, or more perks to a candidate. What the second hiring manager may not try to check, is if the candidate is really worthy of it.

If a candidate is performing well, has a good job profile, and is happy with work, there should be a genuine reason for leaving that organization. If the matter is only about salary, it is understandable. But the hiring managers should also check if they can provide a similar working condition, work, and/or responsibilities to the candidate. Usually, after the honeymoon period, when the reality of the work and working conditions sink in, the salary spirit wears off.

Myths About Quality of Documents

There are several myths regarding the quality of documentation. Here, we will discuss a few of the common myths.

Myth 1: Quality is an Editorial Function

Quality is not just an editorial task. As you are aware, the purpose of product documentation is to communicate relevant information about the product to the people who need that information, when they need that information. A document can be said to be of good quality if is:

    • Clear, concise, and unambiguous.
    • Accurate and comprehensive: If the information is correct, but parts of the product are not covered, the reader(s) will not be able to achieve their goal.
    • Findable and accessible: An often overlooked aspect of quality is its usability in the context of the product. If a user can’t find the information, the objective of the document is not met. Then it does not matter how well it is constructed or how accurate it is.
Fact: Quality is not about just editing the document. It is also about an error-free,  usable, and user-friendly document!

Myth 2: Quality is Applied at the End of a Project

Technical writing is a meticulous process: gathering information, structuring information, writing, rewriting, reviewing, editing, quality checking, and production. Some of the tasks may have to be done a number of times. Letting reviewers find mistakes in a document during the reviewing phase makes the review and rewriting phase a time-consuming process. It also makes the reviewers form a negative opinion about the quality of the work produced by you.

The only way to actually improve quality is to prevent the introduction of errors instead of fixing them. Try to improve the quality of the document by improving the quality of the input i.e., by preventing the introduction of errors in documentation. For this, quality must be defined and then designed into the document, not evaluated only at the end of the writing phase. To achieve quality and hence customer satisfaction, you have to follow certain styles, formats, and processes to help you work in a more professional manner.

So, as tech-writers, try to produce quality drafts, with as fewer editorial and technical errors as you possibly can. For this, you should be able to define and measure the quality of the document. This can be done by determining company-specific standards, styles, processes, and checklists that have to be rigidly implemented for all the documents.

Don’t follow them mechanically, follow them such that you also improve as a writer. This will help to produce documents that are usable and have a high level of quality.

Fact: Quality must be designed into a project, not evaluated only at the end. It has to be taken into account during all the stages of the documentation process.

Myth 3: Writers are Responsible for Testing Documentation

Most of the organizations feel there is no need for testing documentation and justify that it is the writer’s responsibility to write an error-free and quality document. According to them, these aspects should be considered during the writing phase.

They feel that the edits and reviews take care of errors if any and hence there is no need for testing the document. For them, the idea of sparing time to test the documentation seems to be absolutely ridiculous, especially, when there is barely enough time to test the software/product. This usually happens in the following cases:

    • When the decisions of the documentation team are taken by a person who does not know about the technical writing concepts and issues.
    • The persons to whom the documentation manager reports to do not understand the requirements of the testing the documentation.

Fact: Writers are responsible for creating an error-free document, but the QA and/or support engineers are responsible for performing the QA of the documents.

Myth 4: Experienced writers do not need standards and guidelines

Some technical writers feel that standards, guidelines, and checklists are not for them because they are good writers. I remember an instance, wherein a trainee writer declared that she completely disagreed with the measures that are being put forward for quality control (using checklists, guidelines, etc.).

According to her, a system is no substitute for common sense and hence putting a system into place was useless. Now, wouldn’t that mean that all the technical writers around the globe are useless, because not only do they use various quality control systems for documentation, but recommend them as well? This shows how good some writers think themselves to be, but also shows how ignorant they are. What they need to understand is, using guidelines and checklists does not question their writing skills.

    • It is a proven way of reducing errors and improving the quality of the documents
    • It helps in maintaining consistency in the documentation when multiple writers work on a single project.
    • It avoids unwanted discussions and arguments in deciding what was agreed upon sometime back.

If the writers themselves regard standards and guidelines as useless, we should not blame the others for doing so. Documentation standards is actually a formalized database of the decisions about quality-related standard style, language, terminology, document structure, content, and format. Some of them are incorporated directly into word processor templates (font sizes, margins, page layout, indents, bullet formats, and so on).

Other standards (terminology, acronyms, abbreviations, capitalization of headings, preferred spellings, punctuation, and hyphenation) may need to be documented and used by the writers.

Fact: All the writers irrespective of their experience or position in the organization should make use of standards, guidelines, checklists, and follow quality control methods.