Author: Theresa Pojuner

Communicating on the Internet is equivalent to having a face-to-face conversation with someone, except that your dialogue takes place over a network. Emailing, chatting, texting, tweeting, etc., has become a popular form of communication. You can have a conversation with anyone from anywhere and get up-to-date information on what is happening when and where at an instant. This is great, but as with any good thing, you still have to be careful.

Basic practices you should be acquainted with:

• Be attentive of what you write on posts or comments, as everyone will see it. Be respectful and follow the ‘Do Not’ rules mentioned in the previous post on Netiquette.
• Be aware that what is written might be archived or replicated. Deleting or sending an email or chat to trash does not wipe it out completely. So be careful of what you write.
• Be cautious of whom you email/chat with. Make sure you know and trust the individual you are communicating with.
• Be wary and guard yourself against any unwanted email, web sites, or links that you are not familiar with and that do not seem legitimate. This may lead to viruses, bugs, or hidden programs that could corrupt and destroy your system.
• Be careful of your spelling of words as a misspelling can cause a huge misunderstanding. You do not want to be known as the individual who recorded Mr. Mary Jones when you meant Mrs. Mary Jones.
• Be conservative when using acronyms. There are an infinite number of acronyms and there are an abundance of similar acronyms having different meanings. If an abbreviation is used, spell out what it represents before continuously using it as the reader might not be familiar with it. Also, limit its usage.
• Be concise when emailing. In general, enter the purpose of the email in the subject line using as few words as possible to explain the content of the email. Within a business environment, if the content of the email is lengthy, include it as an attachment.
• Be sure you read your correspondence carefully. Make sure you read and understand what is in the email-do not assume. Else, you might reply incorrectly to the email and a host of miscommunications can occur. Likewise, be diligent and reread what you’ve written to ensure that what you’ve written will be understood.
• Be sensitive of the tone you use while writing as the reader cannot see your visual expression and cannot distinguish sarcasm nor annoyance from pure statements; be cordial.
• Be aware that management likes point-by-point information in an email, like a telegram, whereas you can write more informally to a co-worker.

In essence, when writing, chatting, or posting on the Internet, make believe you are conversing face-to-face with that person or group. Be polite and be sensitive to them. As the old saying goes, ‘Put yourself in their shoes’. Or, as the new saying (The Platinum Rule) goes, ‘Treat others the way they would like to be treated’.

A Technical Writer creates and compiles a range of documents. This is especially true when the product involves multiple divisions, departments, or projects. By working across these multiple channels all knowledge gained will be incorporated within several documents. Product specifications, deployment manuals, instructional material, operational manuals, forms manuals, brochures, etc., may need to be written. Within each document, the Technical Writer will communicate what is relevant and be able to present it in a creative manner. Creativity is important when constructing tables, charts, graphics, or diagrams to simplify and enhance details of procedures, processes, business reports, etc. Besides relevancy and creativity, there are other core requirements for specific types of documents. Below are some standard forms of documentation frequently generated during a product’s life cycle. Under each type of document are some fundamental elements.

Requirement Documents (created at the initiation of a project) contain:

• Date and authorization,
• Project scope/overview,
• Task proposal,
• Proposal validation,
• Business goals,
• Specifications,
• Time and expenses,
• Resources and support.

Software and Functional Specification Documents (created for Developers and Analysts) contain:

• Technical details of the product,
• Detailed tasks,
• Database design and schema location,
• Client needs,
• Program functionality,
• System platforms ,
• User Interface,
• Security,
• Error messages.

User /Operations /Training Documents (created for guidance and instruction) contain:

• Guide description,
• Product description,
• Installation and/or log-on procedures,
• Program functionality,
• Required information,
• Prompts and error messages,
• Trouble-shooting section,
• Glossary,
• Reference sheet.

Reference/Cheat Sheets (created as a quick look-up) contain:

• Brief program overview,
• Brief explanation of each functionality,
• Quick ways to accomplish a task,
• Brief trouble-shooting section,
• Index and cross reference sheets.

Quality Assurance/ Test Plan Documents (created for testing) contain:

• Program description and client needs,
• System requirements,
• Program accessibility,
• Functionality,
• Tasks and scenarios,
• Expectations,
• Regression testing,
• Problems and resolution.

SOP (Standard Operating Procedures) Documents (created for routine tasks) contain:

• Purpose,
• People involved/affected,
• Guidelines,
• Revision instructions.
• Procedures,
• Appendix,
• Glossary.

Each of the above documents will be elaborated on in future posts. There are many other types of documents that a Technical Writer produces. The above were selected because they are generally the most common. If there are others that you wish more information on, please leave a comment.

Communicating on the Internet allows you to be part of a community and along with that stems network etiquette rules. Corresponding, writing, or having a conversation on the Internet is no different from having a face-to-face conversation with someone, except that your dialogue takes place over a network. Because a conversation takes place over a network, the standard conversational etiquette rules have been expanded to Netiquette rules.

Some basic ‘Do Not’ guidelines are:

• Do not be rude via the Internet nor email. There are a number of communication avenues, i.e., posts, Facebook, Twitter, etc. No matter which method is used, people should be cordial and respectful to whom they are writing. Would you be happy if someone sent you a critical or cutting remark? As the saying goes, ‘If you haven’t got anything nice to say, don’t say anything’.
• Do not pass on other people’s information. No one is allowed to pass on a person’s information without the approval of the individual. This is a crucial rule to commit to memory especially if you are thinking of passing someone’s personal information. This could lead to a serious offense, so do not even consider it.
• Do not use all capitals when writing as its connotation implies yelling. Bear in mind that the reader cannot see your face and can easily misinterpret its meaning. Appending an emoticon to the capital letters to imply a tease could even be misconstrued as a sarcastic remark. So pay attention to the use of capital letters and only use them for, e.g., acronyms.
• Do not change someone else’s words. What a person writes belongs to them. Do not change someone’s content to be spiteful, harmful, or hurtful.
• Do not send chain letters nor inappropriate links. Not everyone enjoys receiving chain letters. This will just annoy the receiver. If you send someone a chain letter and they respond to you with a ‘please do not send’, then respect their wishes and do not send anymore.
• Do not send spam. Spam is any unwanted email. Set your email options to forward all spam email to either a spam or trash folder where they can all be deleted without any harmful effects.
• Do not spread private chats nor conversations. This is a malicious offense. The conversation you have with someone is private and should remain as private unless they say it is ok to pass the conversation to others. Not following this rule can be damaging and libelous.
• Do not continuously send chat messages to someone who does not reply. Seeing someone on chat doesn’t mean you have to speak with them. Be respectful- if someone does not reply on chat, then they are probably busy.
• Do not send out an email to everyone (i.e., co-workers and managers ) and do not click Reply to All if only one person needs to be the recipient. This is especially true if the other people are not involved with the subject matter. This will only displease fellow associates as they probably receive more emails than they want on a daily basis.

The key rules to remember are to be responsible and respectful. You are accountable for your actions as well as for what you write, so make note of the ‘Do Not’ rules.

In today’s world, a Technical Writer wears many hats and possesses many traits. A Technical Writer will wear hats as an Interviewer, Researcher, Analyst, Editor, and Tester, just to mention a few. The one trait they all have in common is that they must be extremely detailed. The Technical Writer has to be a detail-oriented individual with the ability to communicate to their audience via text and images. The Technical Writer has to have a sense of curiosity in order to understand and write about the framework of a product or technical information. Whether it’s as simple as writing about how and when to press a key or as complex as describing the steps involved in building a new application from inception to completion, the writer will need to be able to communicate every detail effectively.

Some other qualities that a Technical Writer has are:

Interviewing Skills:

The Technical Writer needs to be able to interview subject matter experts, project managers, co-workers, users, and clients in order to gather any relevant information needed to complete a set of documentation. They will use their interpersonal skills to understand the target audience and to find out what they need in order to complete the documentation. They will also use these skills to work with subject matter experts to gather information such as the background of a project, the steps for running routine processes or finding out what changes to the product were needed, made, and why.

Research Skills:

The Technical Writer may need to perform research for various types of tools needed to complete a document. They may need to research for an appropriate storyboard or animation tool to use along with the document to add visual clarity. If the document contains a lot of data, a suitable data diagramming tool may be needed where you can define elements and their attributes, or a querying tool to present relevant data effectively.

Analyst Skills:

The Technical Writer may need to gather and analyze data to produce certain types of requested reports, or to create data files and be able to report on them to management. By knowing how the data was gathered and the mechanisms used to derive the results, the writer could then translate the information, and be able to format and present it in simpler terms. For example, if a computer hardware problem affected data results, the writer would work with those involved to summarize the incident, define the causes, and recommend solutions for presentations to other teams or for future referral.

Testing Skills:

The Technical Writer may need to perform tests to ensure that everything documented was accurate and valid. For example, if Test Plans for the Quality Assurance group were needed to be written, the Technical Writer must write clearly and concisely about reviewed processes, procedures, hardware, and/or software applications as a part of the test plan. To further the example, if an application field that accepts data needs to be tested, the test plan would need to contain every possible scenario imaginable to test out that particular field.

Information Sensitivity Skills:

The Technical Writer has to have an eye for detail and be able to write what the reader needs to know, especially when it comes to confidential information. They have to be able to distinguish what is important to document and what is not. This can be determined by reviewing the requirements of an end user‘s purpose of the document. For example, an IT Systems requirement document could be used by a business sponsor to justify the project expenditure and an IT project manager would use it to make sure all of the high level requirements are a part of the project plan.

So, how do you know if you have the aptitude or talent to be a Technical Writer? If you are a good listener, enjoy learning and enjoy sharing information with others, then you can be a Technical Writer. What distinguishes some writers as Technical writers is that they write about technical subjects within different industries and have the industry knowledge to do so. They could be working within a software, manufacturing, financial, automobile, pharmaceutical, or publishing company and must have familiarity with the industry terminology.

But what types of documents does a Technical Writer create? That question will be answered in the next post. I hope you will enjoy these posts on technical writing as much as I enjoy writing them. If you have any questions or would like more detail on certain topics, please leave a comment.