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

The Case for Simple Numbering

Rather than spend hours coming up with a complex numbering scheme, this might be an excuse to implement something far more straightforward discovered by an extensive readability study at IBM, of which I was a part. My work involved sitting behind a one-way mirror with a stopwatch, watching people take tests that involved, among other things, "how fast can you find Figure 3-4?" We had cameras mounted over the participant's shoulders and could watch them thumb through the documents, and we also monitored eye movements. Then we followed up with a short interview where we got feedback.

Techknowledgecorp (2007). Articles>Document Design>Information Design>Technical Writing

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

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

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

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

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