One of the things my last post made me think about was a benefit of having a technical communicator involved in the design stages of a product. If the designer involves the writer during the design phase, the latter can look at the design with the question, “How will I explain this? Will this be reasonably simple to explain?”

If the answer to the second question is no, then that’s feedback for the designer. And it’s early enough that the cost is lower. The ship hasn’t left port yet, so you can adjust your coordinates while it’s still easy to do so.

Of course, “reasonably simple” is a very loose term. In all of this, I’m talking about your typical product that will be used by the masses, as opposed to something designed for use solely by people with highly technical prior knowledge.

A good exercise would be for the writer to study the design and then try verbally explaining to the designer how the product features work. This saves the time of actually writing something before the product is even developed, but it gives the writer a chance to see if he understands it well enough to articulate it in a basic way. If the designer keeps having to correct the writer, it’s a sign that something is wrong (assuming we have a sharp writer… why wouldn’t we assume that?) A side benefit is that the writer cements the concepts mentally by explaining them at this early stage.

If you try this, as the writer, just keep a thick skin. If you’re not grasping the product, it’s probably something that needs to be adjusted in the design. It’s not a sign that you need to go back to elementary school.

Related entries (auto-generated):

Technical Communication: The QA of Product Design

Problem-Centered Design for Documentation

An Interaction Designer Who Understands the Need for Documentation

“If an App Is Designed Well…”

Team Documentation Design Reviews