Sometimes, You’ve Got to Break the Rules

In a case like this, you don’t need documentation made up of perfectly-chosen words and phrases. Instead, you need something that can be easily scanned, easily understood, and easily digested. Documentation that distills the main points quickly. Far more quickly than even the kind of minimalist documentation that I encourage can.

Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>Technical Writing>Rhetoric

Minimizing Documentation

Is less always more? I’m not sure. But if Apple’s minimalistic designs are any indicator of trends, minimalism in documentation is something to pay attention to. Here are five ideas for minimizing documentation.

Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Technical Writing>Minimalism

How Poor In-House User Documents Cost You Twice

Many organizations produce in-house tools or modify commercially-available tools for their own use. These tools should get documented so they are of use to others in the organization. If this documentation is not created or is poorly written, it costs you twice.

Millman, Barry. Technical Writer Blog, The (2009). Articles>Documentation>Technical Writing>Business Case

Coffee and Documentation

I like the concept of not treating the readers of documentation like idiots. This little card gave me the information that I needed and couldn’t know ahead of time (how much water to use, the filter looks too big but is the right size, only push the button once) without wasting my time by giving me information that I either already knew or could easily guess (I can get water from the sink, I need to use a cup). Can we use this concept in software documentation? What parts can safely be left out so that we are only highlighting the pieces that are really needed?

Miller, Lynn. Designing the User Experience at Autodesk (2009). Articles>Documentation>Technical Writing

Minimal Procedure Content: Reasoning 

The procedure I wrote about creating a Twitter list uses abbreviated content. This post describes the reasoning behind and decisions made in writing the topic.

2moroDocs (2009). Articles>Documentation>Technical Writing>Minimalism

Writing Great Documentation: What to Write 

Tech docs can take a bunch of different forms ranging from high-level overviews, to step-by-step walkthroughs, to auto-generated API documentation. Unfortunately, no single format works for all users; there’s huge differences in the way that people learn, so a well-documented project needs to provide many different forms of documentation.

Kaplan-Moss, Jacob. Jacobian (2009). Articles>Documentation>Technical Writing>Software

Writing Great Documentation: Technical Style 

Now that I’ve discussed what kinds of technical documentation to write, I can move on to the question of how to actually develop a writing style that produces great technical documentation. So how do you learn to write (anything) well? There’s only one answer: you’ll learn to write well if you write. A lot.

Kaplan-Moss, Jacob. Jacobian (2009). Articles>Documentation>Style Guides>Technical Writing

Writing Great Documentation: You Need an Editor 

All good writers have a dirty little secret: they’re not really that good at writing. Their editors just make it seem that way. It doesn’t matter how well you’ve mastered the language; nobody, even grammar geeks, gets this stuff right on the first pass. If you really want to produce great documentation, it needs to be edited.

Kaplan-Moss, Jacob. Jacobian (2009). Articles>Documentation>Technical Writing>Technical Editing

Quick-Start Guides Require a Minimalist Mindset 

The point of a quick-start guide is, as the name says, to help the users get on their feet as fast as possible. This requires the writer to ask, “What is the absolute minimum that someone needs in order to get started?” The next best question is “What is the user going to do the most often?”

Minson, Benjamin. Gryphon Mountain (2008). Articles>Documentation>Technical Writing>Minimalism

Five Skills for Managing Documentation Projects in an Agile Environment 

Sometimes, the Agile software development methodology seems like it could be renamed the “Fly by the Seat of Your Pants” methodology. But really, it means that you need a somewhat different set of project management skills for your documentation. I could certainly improve in these skills, but here are a few I rely on in an Agile environment.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Documentation>Technical Writing>Agile

Quick Reference Guides Are More Useful Than a 150-Page User Doc 

I’m working on a project to boil a 150-page software user document down to a one-page reference guide that can be tacked to a CSR’s cube wall. Our goal with the one-page reference guide is to give the CSR a description of all the navigation elements and application functionality so they can quickly navigate to where they want to go without first having to trudge through the complete 150-page user doc.

Creel, Ron. Your Writing Dept (2009). Articles>Documentation>Technical Writing>Quick Reference