We interact with a world of multiple overlapping patterns. Sometimes these patterns enhance each other. Often, though, they interfere, obscuring what’s important.
orange, red, yellow
scent and smell of fallen leaves
crossed by shadow lines
Do we have a bias toward adding to things? A post at Awareness is Everything points to some examples, and to the alternative approach of changing and growing by subtracting rather than by adding. Why?
We’ve all experienced the reason. Depending on the setting, we call it information overload, multitasking, clutter, background noise. Noticing, doing, finding, or hearing something in those circumstances challenges our pattern-matching abilities. Providers of information sometimes mistakenly feel that providing more information will make things more clear. Too often, though, we’re just adding to the clutter.
What to subtract
Indiscriminately knocking down interior walls in a building certainly results in fewer walls, but not necessarily in an acceptable “open floor plan”. Similarly, hacking away at your content will result in less content, but probably not in more usable content. Here are three suggestions for judicious trimming.
Your perspective
Repeat after me: “I am not my audience.” Things that confused you might be obvious to your audience. Things that seem obvious to you might not be so clear to your readers. Don’t write the content for yourself.
In technical writing, another perspective that needs to go is that of your subject matter experts (SMEs). Part of the problem is that they’re experts – in the subject, but not necessarily in the user. In the company where I worked as a writer, most SMEs were the software developers for the product. They had written software features that were very useful. They were proud of their work, and rightly so. Unfortunately, they wanted their accomplishments chronicled in the user documentation.
Ironically, the features that have the best designs actually need the least added user assistance. Often, they’re so good that they really shouldn’t be in the user guide because they work so well. The solution to this dilemma is to let the user guide serve the user, not the SME.
Your preconceptions
Repeat after me: “I don’t know what my users need.” Then fix that. Get out and talk to real users. Observe them in the context of the activities you’re supporting. They will open your eyes and show you things you never knew your were missing.
The fine print
In his book The Nurnberg Funnel, John Carroll describes an approach to creating minimalist manuals as contrasted with systems-style manuals. Carroll reported that people using minimalist manuals were able to learn faster, make fewer mistakes, and correct more of the mistakes they made.
Too often, we crowd the user documentation with a bunch of “just in case” content. I think of it as the fine print, even though it’s usually set in the same typeface as the rest of the body text. We don’t trust our readers to be grown ups. As we add more and more of this kind of content, a manual that started off user-centered ends up more and more looking like an exhaustive description of the system.
To make manuals more useful, take advantage of your readers’ prior knowledge, allow them to reason, explore, learn, make mistakes, and recover quickly from their mistakes.
What are your thoughts? What do you subtract in order to make a better result?