Month: April 2020

Conversation starters

Asking your SMEs or product owners for information to populate a user guide and then waiting for that information is a sure fire way to never completing said user guide (unless you’re among the lucky tech writers to have SMEs/product owners who enjoy writing user documentation).

Instead, research the product and then write a first draft to the best of your understanding, even if it’s just headers. First drafts don’t have to be perfect. Send your SMEs/product owners that draft and ask them what you’re missing.

It’s far easier to critique than create.

Empathy

Technical writers are pain relievers.

In most cases it’s not physical pain. It’s the pain your audience feels when they don’t know how to complete a task, or when they’re trying to figure out why the app isn’t working the way it’s supposed to. Users just want to get their job done and go home, but they can’t because the #$%@! software isn’t working.

Pain.

Good technical writers figure out their audience’s pain and provide the information needed to relieve it.

How do you figure out your audience’s pain? Talk to your product support teams. They can tell you stories…

Jack of all trades

I was planning a post on the non-writing skills of a good technical writer, but Tom Johnson at IdRatherBeWriting.com beat me to it:

How is the role of the technical writer evolving? It seems we’re moving away from writing and more towards other roles, such as reviewer/convener, user champion, editor, publisher, and promoter. However, it’s difficult to gauge change, especially across different job categories. In some scenarios, writing might never have been why we were hired.

Read the whole thing.

I’d say 3/4 of my day-to-day job is spent on non-writing tasks. Employable technical writers always have been (and always will be) flexible and seek ways to add value to the organization where ever they can.