Zero's eye

뻔한 논리같지만 TW로서 반드시 지켜야 하는 Rule입니다.^^
 
1. Paper is Permanent
-Mistakes don't go away.
-Errors destroy the credibility of the product and the company.
-You won't be there to verbally clarify things.
-Proofread and edit thoroughly!
 
2. Know Your Audience
-Make safe assumptions.
-Distinguish the user from the market.
-Tap internal sources (marketing, tech support, etc.)
-Get customer contact.
-Learn to deal with mixed audiences.
 
3. Highlight Hazards
-Find hidden hazards.
-Rank warnings by severity (warning, causing, note)
-Make hazard visual clear. (indent or group)
-Place warnings appropriately.
-Explain ramifications.
-List prerequisites.
 
4. Break It Out
-Always remember that users don't read blocks of text!
-Use tables for values and specs.
-Use numbered lists for procedures and instructions.
-Use bulleted lists for features and other non-sequential information.
-Use flowcharts for branching processes.
 
5.Don't Write "Blind"
-Never rely on second- or third-hand information!
-See it, touch it, use it.
-If you can't do it, you can't explain it.
-Think and ask; what they want is not always what they need.
 
6. Be consistent
-Decide how to refer to the product.
-Pick one technical term.
-Consider interface elements and actions.
-Don't forget style, fonts, and layout.
-Use a style guide!
 
7. Signpost
-If it isn't documented, it doesn't exist.
-If it isn't accessible, it isn't documented.
-Never make users read material that isn't appropriate for them.
-Use layout and typography to indicate relationships of elements.
-Add roadmap in online Help.
 
8. Don't Violate Standards
-Recognize the difference between a legitimate standard and a bad de facto rule.
---(You need a good reason to change a standard.)
-Go to the source for the certification and guideline standards.
-When no rule exists, UDSG!
 
9. Contemplate Before You Illustrate
-Do you really need it?
-Do you need all of it?
-Does it enhance the text?
-Does it confuse the reader?
-Is it placed properly?
 
10. Cut the Fluss
-Remember, fluff kills!
-Watch out for these fluff items:
  "If you want to, you can..."
  "You may at this point need to..."
  "It is recommended..."
  Please
  Might, can, choose to
  Vague languages (more, some, bigger, a lot)
-Where possible, use telegraphic style.

Become a Great Technical Writer
even if you are not a great writer

Are you contemplating or beginning a career in technical writing? Have you been asked to create the user guide for your company's software application? Have you been asked to hire and manage a writer?

Where do you begin? How can you get an interview when you have no experience? How do you know if the technical writer on your team is doing a good job or a poor one? Can you find out before you hire the person?

Technical writers (known as technical authors in the United Kingdom) translate and organize complex information into user guides that any person can understand and use with ease. But in the 16 years that I have been in the business, I have often found myself working with writers who do not really know how to write manuals or use the desktop publishing software, and with clients who are not entirely sure what to expect from writers. More often, I have had to clean up a documentation mess left behind by a previous writer. This asymmetry between expectation and output can create technical writers who unknowingly make the same costly mistakes year after year, and clients who regard technical writers as a high-cost, low-value drain on the company's bottom line.

This site, whether you are a manager or a technical writer, will get you all working on the same page. If you are a writer, you will see that technical writing requires skills other than the ability to write. In fact, it is possible to write great user guides even if you are not a great writer. You don't need to spell perfectly (I don't), and you don't need to know the difference between a dangling participle and a dangling gerund. But although you don't have to be a great writer, you will probably be happier in the job if you like writing and are a competent writer. If you find it difficult to organize your thoughts and put them down in writing, you might find the job boring, unpleasant, and unrewarding.

In fact, writing is only a fraction of what you will do as a technical writer. This site, therefore, does not show you how to become a great writer—many other sites exist to help you with your grammar and style—but it does provide you with information, skills, tips, and techniques that can help you become a great technical writer.

Notes For Managers
If you are a manager, this site shows you what you can expect from the technical writers on your team. Although this site speaks mainly to the writer, you will easily be able to develop from the information provided your own expectations and requirements for your writers. This site will also help you distinguish between good and bad technical writing and it will tell you what to look for when hiring a writer. In particular, you should read the first three articles below.

:: 관련 링크 ::
http://www.docsymmetry.com/index.html

"기술 전문 저술가" [技術專門著述家, technical writer]

정보 기기 또는 전자 기기에 관한 기술적인 내용을 일반적인 경향으로 알기 쉽게 설명하고, 과부족 없이 정보를 제공하기 위한 문서를 쓰는 사람.

엠파스 IT용어사전에서 검색한 것이다.

현재 내가 일하고 있는 직군이 이것인데.. 흔히들 메뉴얼 제작하는 것만 생각할수도 있다.
내가 일하고 있는 부분은 Component Software 를 활용하여 Application 을 쉽게 개발할 수 있도록
Guide 를 제시해주는 문서를 만들고 있다. 뿐만아니라 Software Engineering Process 중에 투입되어
개발자들이 설계문서를 작성하는데 Writing 이나 Documentation 관련된 부분에서 Support 를 하고 있다.