#20686
I'll never be able to be a technical writer. How do those people do it?
Osherove, Roy. ISerializable (2003). Articles>Documentation>Technical Writing>Help
#30132
Writing Procedures Like a Pro: The "How To" of "How To's" 
Do you need to brush up on your procedure-writing skills? Or do you need to teach others--like clients or coworkers--these valuable skills? If procedural writing isn't your focus, keeping these skills honed is a challenge. This workshop is designed for communicators at all levels who must--in some fashion--tell people how to do something. During this highly interactive workshop, you'll find out about the differences between process descriptions and procedural writing, some tips for planning procedures, and the secrets of writing techniques for procedures. So bring your thinking cap, and join a couple of seasoned writers/instructors for this fun and informative session!
Edgerton, Rebecca J. and Jill Nicholson. STC Proceedings (1999). Articles>Documentation>Writing>Technical Writing
#20189
Large manuals are expensive to write, produce, and ship, and may make a product seem mare diflcult or complex than it really is. Shorter manuals can decrease telephone support calls, provide a challenge to the writer, and save time and money. With careful planning and preparation, diJjCerent writing and design techniques, and participation in product design, writers can shorten manuals and make users more willing to read them.
Sommerville, Heather M. STC Proceedings (1997). Articles>Documentation>Editing>Writing
#14415
Writing User Manuals from the Middle Out 
You need to write the user guide for a complex product. There must be a dozens of functions and hundreds of tasks that can be performed with the product. Where do you begin? How to start writing? Conventional wisdom says: start at the beginning with an introduction to the product, and work your way through each function or task in the order the customer will use them. Don't! Here's a tip I learned the hard way after my ninth or tenth year tech writing: start in the middle, and work your way outward. This article presents a method of writing user documentation that you may find easier and more effective than starting at 'Chapter 1.'
Rice, William H. IV. WilliamRice.com (2001). Articles>Documentation>Writing
#19861
Your Role in Supporting Sales-Force Automation
When given a user manual to write or a Web site to put together, your role as a technical communicator is clear. But what is your role when supporting sales tools? How can you help your company market their technical products? The first step to understanding your role is to understand what a sales-force automation (SFA) solution could mean to your company. This workshop defines SFA and the potential benefits. Further discussion covers deciding on an information delivery method, determining data organization and management, and identifying audience needs.
Caldanaro, Regina M. and Jodie Pait. STC Proceedings (2000). Articles>Documentation>Writing>Technical Writing
#24120
The Zen of Minimalism: Designing a Top-of-Class Manual for Beginners and Advanced Users
Can using minimalist documentation improve accuracy and learning speed for beginners as well as for advanced users? I tested this question using Microsoft Access for Windows 95 ® and three different third-party manuals explaining this product. Then I set up three main tasks for the user in a usability test. For each task, I provided the task description in blue type, and then copied the appropriate documentation in black. Documentation for each of the three tasks was reprinted from a different book.
Stieren, Carl. Simware (1998). Articles>Documentation>Technical Writing>Minimalism
#32092
A Curmudgeon's Guide to Computer Documentation
Is documentation a bad word? It is if you’re the Curmudgeon, a character I invented, who some say bears an amazing resemblance to … me.
West, Mike. MBWest.com. Articles>Documentation>Technology>Technical Writing
#32093
A very brief review of the first edition of Edmond H. Weiss’s How to Write a Usable User Manual.
West, Mike. MBWest.com (2006). Articles>Reviews>Documentation>Technical Writing
#32145
By partly adopting the process suggested by Daniel Brolund we, the technical writing team, can be involved right up front and the documentation can be one of the methods used to validate the software as it is being built.
McLean, Gordon. One Man Writes (2008). Articles>Documentation>Writing>Technical Writing
#32161
Collaborative Walkthrough Video
Collaborative walkthroughs are a technique that my team used while rewriting our Help and adopting DITA. We believe that we were able to improve the user experience by improving the collaborative experience.
Bennett, Miranda. On Writing (2008). Articles>Documentation>Collaboration>Technical Writing
#32384
Technical writers write with authority. That’s the job: to present the subject with authority, so the reader will feel confident about the accuracy of the information or confident about using the software. There’s no place for hedging. You write, ‘Press the OK button’. You don’t write, ‘Press the OK button – I think.'
Bristow, Gemma. Inkjuice (2008). Articles>Writing>Technical Writing>Documentation
#32776
Placing Value on User Assistance
User assistance writers are often the Rodney Dangerfields of the UX world, bemoaning the fact that we don’t get any respect. I think the real problem is that user assistance folks are not particularly good at communicating the ways in which we add value to an enterprise. This column explores two models that show how user assistance adds value and how we can communicate that value to those who pay our salaries—something I would like to encourage other user assistance writers to do.
Hughes, Michael A. UXmatters (2008). Articles>Documentation>Technical Writing>Help
#32816
Learn about theoretical and practical examples of merging DITA (Darwin Information Typing Architecture), a structured authoring methodology, and wiki’s freeform authoring and editing capabilities.
Gentle, Anne and Lisa Dyer. Intercom (2008). Articles>Documentation>Technical Writing>Wikis
#32817
The "Quick Web" for Technical Documentation
So how did the wiki become a seemingly permanent fixture in the landscape of today’s Web? Which wikis have succeeded as technical documentation, and how can we replicate their success?
Gentle, Anne. Intercom (2007). Articles>Documentation>Technical Writing>Wikis
#32823
Don't Let Your Product's Features Become Expensive Flaws
Your product's unexplained features can turn into costly flaws. This article describes three real-world products with just such "features." It presents ways you can prevent these feature-to-flaw conversions by improving the User Documentation for your products.
Great Technical Writing (2008). Articles>Documentation>Usability>Technical Writing
#32824
Before you release a product, have some people use it. From these "test users" get solutions to problems, tips and knowledge that would help your real-life Users. Put that information in your User Documentation, and on your product support website.
Great Technical Writing (2008). Articles>Documentation>Technical Writing>User Centered Design
#33303
'Read Rage' Over Instruction Books
"Read rage" is sweeping the UK - as consumers become fed up with the often incomprehensible language used in many of the instruction manuals produced by manufacturers.
Channel 4 (2008). Articles>Documentation>Technical Writing>United Kingdom
#33331
A glossary is an alphabetically arranged list of terms, with a definition or an explanation of each term. A term can be a single word or many words. Typically, in a printed document, the glossary is at the end of the document. Usually, in online help, each term in a topic, or the first instance of a term, has a popup that explains the term.
Unwalla, Mike. TechScribe (2007). Articles>Documentation>Technical Writing>Glossary
#33334
Writing for an International Audience
Ideally, software and its documentation is localised (translated) into the languages of the target markets. However, in many cases, it is not cost-effective do this. Even if the target markets are the English-speaking countries, differences exist between the way English is used in the US, the UK, and Australia for example, and it is easy to cause confusion. This article examines some issues.
TechScribe (2007). Articles>Documentation>Technical Writing>Localization
#33337
FAQs don’t have that great a reputation, but recently, I’ve been working on FAQs for a client. Their computer help desk was annoyed about answering the same things again and again. Why not divert potential callers to a FAQ instead?
Jarrett, Caroline. Usability News (2007). Articles>Documentation>Technical Writing>FAQ
#33370
Normally I like to write positive stuff and I really love Uxmatters.. it’s a great site. BUT, the recent article PDF Manuals: The Wrong Paradigm for an Online Experience from my perspective is pretty much everything that’s wrong with Help today.
Lang, Keith. UI and Us (2008). Articles>Documentation>Writing>Technical Writing
#33372
I am ill equipped to write for an emerging segment of the marketplace. But that doesn't mean I'm used up like a worn-out number two pencil stub (my favorite simile these days). But it does mean that I need to reevaluate where and how I add value.
Hughes, Michael A. User Assistance (2008). Articles>Documentation>Technical Writing>Multimedia
#33465
An error message is text that is displayed to describe a problem that has occurred that is preventing the user or the system from completing a task. The problem could result in data corruption or loss. Other message types include confirmations, warnings, and notifications. The guidelines in this topic are intended to help you write clear error messages that are easy to localize and useful for customers.
Microsoft (2006). Articles>Documentation>Writing>Technical Writing
#33476
The Sacred Cow Blocking the Road
When product teams ask technical writers to document software products, writers usually start their projects by analyzing the tasks users will perform when working with them. A task analysis generates a list of procedures—plus the supporting information users need to follow them—and eventually results in a document in which sequentially numbered instructions are the dominant type of information—neatly organized under user-centered task headings and preceded by enabling knowledge. It sounds ideal, classical even. The problem? Users don’t read procedures.
Hughes, Michael A. UXmatters (2007). Articles>User Experience>Documentation>Technical Writing
#33477
Placing Value on User Assistance
User assistance writers are often the Rodney Dangerfields of the UX world, bemoaning the fact that we don’t get any respect. I think the real problem is that user assistance folks are not particularly good at communicating the ways in which we add value to an enterprise. This column explores two models that show how user assistance adds value and how we can communicate that value to those who pay our salaries—something I would like to encourage other user assistance writers to do.
Hughes, Michael A. UXmatters (2008). Articles>Documentation>Technical Writing>Workplace
