#33865
Why Bother With User Documentation in Recessionary Times?
In recessionary times, organisations should focus on getting sales from existing customers - so customer retention becomes ever more important.
Cherryleaf (2009). Articles>Documentation>Business Case>User Centered Design
#33894
Lessons Learned with Quick Reference Guides: Timing and Truth
I should never fully trust anyone on a project. I don’t mean this disrespectfully, because I work with competent, talented professionals. But no one has the full picture of how the application will truly work. The quality assurance (QA) engineer usually has the clearest picture. The program manager and project manager are often living in a slightly different world, full of a vision of how the product should work and how they expect users to interact with it, but sometimes they’re missing important nuances in the actual implementation. The interaction designer builds prototypes and assumes the developers will build them to spec, but since the prototypes are usually HTML-based, and not in Java or .NET, variances are inevitable.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>User Centered Design>Emotions
#34025
Wurman’s LATCH Model of Information Organization For Technical Documentation
Technical writing has its mechanical aspects that need to be mastered. A good technical writer must know how to use English effectively as well as various software products to produce acceptable technical documents. But I wish technical writing were all about that. The hardest part comes before one even sits down in front of a computer to type the first word. The hardest part in documenting anything is organizing the information in a way that makes sense from the user’s point of view. Otherwise a technical document suddenly looks irrelevant.
Akinci, Ugur. Technical Communication Center (2009). Articles>Information Design>Documentation>Technical Writing
#34093
User assistance can add value to a product or Web service’s business model by influencing how deeply users adopt new features or services. As more products employ pay-as-you-go models like that of SaaS (Software as a Service), the contribution user assistance makes becomes increasingly more important.
Hughes, Michael A. UXmatters (2009). Articles>Documentation>User Centered Design>Help
#34378
User Paradox with Not Reading User Manuals
Users would save time by reading the manual, but instead they try to figure the application out themselves and then get lost/frustrated as they end up spending even more time getting up to speed with the application.
Johnson, Tom H. I'd Rather Be Writing (2007). Articles>Documentation>User Centered Design>Technical Writing
#34385
What Technical Communicators Can Learn from Comics 
Citing the rise of graphic novels, comics, and in particular, Google’s new web browser Chrome, which has a comic-book-style manual, Opsteegh argues that technical communicators can learn a thing or two about conveying information from graphic novelists.
Opsteegh, Michael. Intercom (2009). Articles>Information Design>Technical Writing>Documentation
#34444
Why do product manuals sound formal and stiff-upper-lipped? Why don’t users read manuals? These questions have haunted the precincts of Technical Writing for quite some time now. From what I have seen in Indian writers, I am forced to conclude that English Composition, as we were taught in school, is the culprit.
Kumar, Suman. Indus (2009). Articles>Documentation>User Centered Design>Rhetoric
#34485
Modular Docs Part 1: Why You Want Modular, Topic-Oriented Documentation
When documents are built from components, and the components can have contextual variations, it becomes possible to construct built-to-order documents "on the fly", in response to user demands, rather than having to pre-create static versions of all possible variations. Once such a system is in place, it becomes possible for users to further customize the results by modifying the list of selected topics, rearranging their order, or even by adding new topics.
Armstrong, Eric. Sun Microsystems (2008). Articles>Documentation>Information Design
#34489
Creating Topics: Where do you Draw the Line?
It's hard to look at a page of text and try to decide where to divide things to create individual topics. That "bottom up" approach is kind of pointless, in fact. There are better ways.
Armstrong, Eric. Sun Microsystems (2008). Articles>Documentation>Information Design>Technical Writing
#34548
A musing on the need to balance documenation that looks good with documentation that has substance.
Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>Document Design>Technical Writing
#34587
How to Avoid Extinction as a Technical Communicator
Although there will always be a need for people to explain technical material non-technical people, Ellis Pratt said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way rather than merely creating it.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Multimedia>User Centered Design
#34613
How To Create A FAQ Page Your Customers Will Love (And Might Even Use) 
What FAQ pages have become are elephant graveyards of non-information, the equivalent of the Miscellaneous file folder, the place where information-we-didn’t-know-where-to-put was dumped. The challenge of creating a FAQ page that customers will find useful has several aspects to it, but can be accomplished with a lot of planning and a little strategic work.
Bailie, Rahel Anne. Content Wrangler, The (2009). Articles>Documentation>User Centered Design>FAQ
#34637
Documentation Usability: A Few Things I’ve Learned from Watching Users
Even though your customers may not read manuals, your tech support team probably does, which means someone is reading the manuals and using them to help others. But if your users find it easier to call someone, wait on hold for an agent, and then ask the agent a question rather than find the answer in the help, maybe your help materials aren’t very usable. Maybe increasing the usability of your company’s documentation could alleviate the need users feel to seek answers from another source.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Usability>User Centered Design
#34638
Changing the Rules of the Game for the Benefit of the User
In this presentation, Joe Sokohl talks about gathering user research prior to designing and implementing your help deliverables.
Sokohl, Joe. I'd Rather Be Writing (2008). Articles>Documentation>Audience Analysis>User Centered Design
#34639
Starting Points with Quick Reference Guides: Gathering Before Designing
Dan Roam explains that drawing pictures can help you solve problems. He says the first rule is to “collect everything possible up front.” After collecting all your information, you then “lay it all out where you can look at it.” By laying out all the information, you can grasp the whole of it, make connections between various parts, see the important sections, and recognize patterns.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Information Design>Planning
#34711
Part of the problem in our attempt to demonstrate value is that our help deliverables look the same as they did 15 years ago, more or less. Online help and a PDF manual. It’s not a format that engages users. The web marches forward with innovation after innovation, while the technical communicators are figuratively hunched over keyboards, staring at CRT monitors, wearing 1950s horn-rimmed glasses, typing away.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>User Centered Design
#35158
Tips To Create A Clean Structured About Page
When it comes to an about page, think outside the box. Try to think of something new and creative that’s different form the rest of your site. Of course display images of you / your staff, and descriptions of each, but try to lay it out in a very fun way, whistle keeping it clean and readable.
Johnson, Andy. Web Design Tutorials (2009). Articles>Web Design>Documentation
#35190
Calling Accessible Context-Sensitive Help with Unobtrusive DOM/JavaScript: A Help Authoring Guide
This Fast Track tutorial demonstrates two methods to call Context-Sensitive Help in a Web Form. We'll discover how Unobtrusive DOM/JavaScript achieves the desired result in calling Context-Sensitive help, and demonstrate how to keep the Structure, Presentation, and Behavior layers of a web page completely separate from one another ensuring good practice with current web standards and accessibility rules.
Palinkas, Frank M. helpware.net (2009). Articles>Web Design>Documentation>Help
#35210
As help systems continue to evolve, whatever name they are called, we will increasingly have to face responsibility for their content, and bring their expertise to what we write. The new systems provide us with all the required tools that tell us the problems with their content. It is up to us to leverage that information to provide better content, and act as ambassadors for products that we write. If writers can go a step ahead, and use their help information to sell products, and reduce the burden on customer support, we would have truly arrived.
Kurnool, Preran. Indus (2009). Articles>Web Design>Documentation>Help
#35301
What do the Users Really Want?
I have no idea what our users want. I do know they want information, and I know they want that information to be kept up to date as our product evolves and as far as those basic needs are concerned, I’m happy that we are meeting them. Beyond that I admit I’m not really that sure.
McLean, Gordon. One Man Writes (2009). Articles>Documentation>User Centered Design>Surveys
#35407
While I'm a firm believer in the primacy of content over appearance, aesthetics are definitely a part of drawing people into documentation and engaging them. There's nothing wrong with making online assistance or a printed manual attractive. It doesn't need to be a beautifully-designed work of art, but it should be something a little more than blocks of black text on a white page.
Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>Document Design
#35435
What does structured authoring mean to you? Structured authoring is a publishing workflow that lets you define and enforce consistent organization of information in documents, whether printed or online. What it means to me: defining a goal and assembling architected topics to help the reader achieve that goal.
Vazquez, Julio J. SDI Global Solutions (2009). Presentations>Documentation>Information Design>DITA
#35627
How Apple’s Setup Guide Shows That It Thinks Different
Seth Godin believes that everything reflects what you stand for—right down to your technical documents. Ever looked at Apple’s tech docs?
Godin, Seth. I Heart Tech Docs (2009). Articles>Documentation>User Centered Design>Macintosh
#35677
What Information Developers Can Learn from Software Developers
The shift in information development from a narrative to a modular writing style reflects the established shift towards modularization of source code. What can information developers learn from software developers? What are the challenges and benefits of the modular approach?
Higgins, Paul. TC World (2009). Articles>Information Design>Content Management>Documentation
