글
Ten Golden Rules of Technical Communication
IT Tech
2007. 1. 23. 13:44
뻔한 논리같지만 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.
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.
'IT Tech' 카테고리의 다른 글
MS Office 2007, 무엇이 달라졌나 (0) | 2007.01.25 |
---|---|
STC 멤버쉽 가입 요금에 대한 안내 (0) | 2007.01.25 |
훌륭한 Technical Writer 가 되기 위해서.. (0) | 2007.01.23 |
어도브 아크로뱃 8 신제품 발표회 (3) | 2007.01.16 |
오픈도큐먼트로 향하는 세계「한국은 조용∼」 (0) | 2007.01.05 |