Overlooking The Obvious

In my other life, I work with a guinea pig rescue, handling their PR, various online projects, and public education appearances. As such, I have presentations in long and short versions, for adults and for kids, for solo talks and for crowded adoption open houses. When you do this enough, you convince yourself that you’re prepared for anything.

Then you get in a room with little kids. 

Over the summer, I did a joint presentation with two other rescues. Our audience was three adults, nearly a dozen kids under 10, and a pre-teen boy. With a guinea pig stretched out on my arm, I talked for a bit then switched to a Q&A format. While I’d kept my points simple and age-appropriate, their questions quickly made me realize I should have taken some cues from Steve Irwin or Jeff Corwin and remembered to include the really basic stuff.

• What colors do they come in?
• Is their hair always short?
• When their hair is long, can you put bows in their hair?
• Why are their ears like that?
• What colors are their ears? Do they match their fur?
• Why do their noses wiggle? What colors are their noses? Are they always pink?
• Where do they go to the bathroom? Do they go to the bathroom a lot?
• What would they do if a spider got in their cage? In the wild, in the caves they live in, do they see spiders there? What do they do then?

The experience was a reality check about the ruts we get into when we’re too close to our material. The kids’ questions weren’t difficult to answer, but I’d honestly gotten into such a habit with the discussion points that I tried to cover in presentations that I’d overlooked the fact that my audience’s information needs might be much simpler.

As technical writers, we risk falling into the same ruts — either by our own design or by external pressures. The risk increases if we don’t have a lot of direct contact with users and are forced to rely on second- or third-hand information about them.

In one software documentation job, the product management team was fixated on documenting how to use our reports with custom distribution ranges (the latest enhancements) and customer segment filters. When you read our help desk logs, we had a lot of users trying to make sense of the data when the same report was run with a basic frequency metric and standard fixed deciles.

This was part of the reason why I liked substituting in our user training course. I inevitably came into direct contact with users who, even when they’d used our software for a year or two, were proof that the product managers’ assumptions about what our users knew and understood was partially…at minimum…off base. I typically left with a short list of questions that I wanted to make sure were answered in our documentation.

As we log years into a job with the same company, building a detailed knowledge of the product lines we document and using that knowledge as a way to defend our turf and demonstrate our value, it’s easy to forget some simple realities.

• No matter how long a product is out, there will always be new users discovering it each year. (How many people do you know who are just now using scanners or making their first long-distance calls on Skype?)
• Just because we work with a product for several hours a day every day doesn’t mean our users do. There are reports they only run once in a blue moon. They only replace the toner cartridge in the photocopier when the admin assistant is on vacation. You get the idea.
• Technical proficiency in one area doesn’t guarantee proficiency (or ease of learning) in another.
  A mechanic who knows how to repair an engine in a $15 million aircraft can be baffled by a printer driver issue on a Windows XP system.
• A new feature in an existing product still has a learning curve because it’s just that — new.

Where might you be overlooking the obvious?