|
Technical Writing
Skills
What are
"technical documents"?
And why will your people benefit from learning
how to write them better?
Technical documents? They come in all forms and sizes: market research
studies; project tracking reports; phone system instructions; job descriptions.
Even an inter-office memo explaining a change in policy. Any kind of
objective, informative writing counts as a technical piece.
Why you? Because there's so much riding on your ability to write this
kind of document; If the writing you and your people do is confusing
and hard to follow, readers stop reading (no matter how much time or
research went into it).
But when your writing is clear and to-the-point, your internal and
external clients will look forward to reading documents you've authored.
Problem is, the odds are against you.
Most people cringe when a technical-looking document
lands on their desk. After all, who wants to wade through long paragraphs
filled with tedious details? It's not easy to translate technical terms and difficult data into
everyday English that people will want to read.
But this workshop will turn the table in your favor.
Your staff will discover a powerful, proven writing system designed
specifically for technical assignments. And you'll learn specific skills
to help you:
 |
Sort information,
organize your thoughts and cut to the core of a complex issue |
 |
Write in
language that matches your readers' level of experience and understanding |
 |
Summarize
difficult data and intricate details in a crisp, concise overview
|
 |
Create strong
transitions that keep your readers moving from one point to the
next |
 |
Use design
principles that grab attention and guide your readers where you
want them to go |
 |
Create illustrations,
charts, graphs — even multimedia visuals — that support your writing
and help clear up confusing material |
Use the skills you learn at this course, and you'll notice a big difference
in the ways people respond to your writing —
 |
Your thoughts
will be better organized — enabling readers to make better-informed
decisions. |
 |
You'll make
your point quickly and clearly, saving valuable time for everyone.
|
 |
Your names
on a document will translate to "Read me now" in the minds of
the people you're writing to. |
Who should attend?
 |
Marketing,
finance and budget analysts |
 |
Managers,
supervisors and team leaders |
 |
Corporate
communications personnel |
 |
Operations
and I/S people |
 |
Scientists,
engineers, technical specialists |
 |
Researchers,
lab techs and students |
 |
Computer
programmers, service and sales people |
Especially helpful for support staffers!
Whoever does the "write-ups" for your team projects, reports or analyses
will benefit from this training.
For anyone who writes:
 |
Progress
reports |
 |
Job/task
descriptions |
 |
Project results |
 |
Analyses
and recommendations |
 |
Product descriptions |
 |
Research
reports |
 |
Feasibility
studies |
 |
Instructions/manuals
|
 |
Abstracts |
 |
Executive
summaries |
— or any other document intended to instruct and inform
Program Agenda
Setting a clear course, so your writing stays on target
 |
"Clustering";"mind-mapping";and
other handy techniques for sorting and structuring technical information
|
 |
How to size
up your readers' knowledge base and experience level |
 |
2 questions
you should answer before you begin to write |
 |
What tone
should you take? Factors to help you decide |
 |
When to use
the memo-length, short or formal formats for your reports |
Ways to organize your thoughts and outline your document
 |
"Formulas"
for structuring various types of technical documents |
 |
When to put
information in an appendix |
 |
2 reasons
to add an executive summary — and when to write an abstract instead
|
 |
4 elements
you should always include in abstracts and summaries |
How to write a first draft, painlessly
 |
Proven ways
to bust through writer's block |
 |
Writing descriptions
that detail physical characteristics or give measurable "specs"
|
 |
Exercise:
Practice writing a technical description (for a job, object, function
— whatever is most relevant to you) |
 |
How to write
tight technical reports |
 |
How to write
a condensed overview that helps people decide whether or not to
read your entire document |
 |
Ways to
make dry manuals reader-friendly |
 |
Specific
"dos and don'ts" for writing technical instructions and manuals
|
Ways to measure your message to see if you met your objectives
 |
Questions
to help you judge your first draft |
 |
When it's
OK to use industry jargon — and when to write in layman's language
|
 |
Exercise:
Look at some technical writing samples, and see if you can pinpoint
where the message gets muddied — and how to clear it up |
How to find what's not working, and fix it
 |
Specific
words to avoid in technical writing (they undermine your objectivity) |
 |
How to strengthen
transitions, so readers move more easily from point to point |
 |
Exercise:
Practice writing instructions for completing a simple task — then
revise them so they're even easier to follow |
Designing documents that grab attention and keep your readers interested
 |
How to use
headings, subheads and captions to help your readers find their
way around your writing |
 |
Simple ways
to add "visual relief" to text-heavy documents |
 |
Tips on using
pie charts, bar graphs, line graphs and flow charts |
 |
How to use
diagrams and "schematics" to illustrate physical elements (and
the relationship between them) |
 |
The finer
points of page layout: |
| - |
White space,
margins, line spacing |
| - |
Justification,
borders |
| - |
Bullet
lists, symbols and "dingbats" |
 |
Adding emphasis with
fonts, callouts, boxes and shading |
Back
to the "Corporate Seminar" Index
Contact
us and bring this Seminar to your organization
|