Recently, we purchased a new coffee maker for home to replace the five-year old brewer that had given up the ghost. The new coffee maker lasted exactly three days before the basket broke along the top rim, which made it fit poorly, and the latch broke that secured the swing-out brewer basket in place. The only way to make coffee was to use a piece of duct tape to hold the basket in place so the water went into the coffee grounds. And we NEED coffee at our house, so this was not…convenient.
This brought to mind deficiences in product quality in the news recently that ranged from annoying (errors in cookbook recipes) to life-threatening (lead in toys). It made me think about quality and my responsiblity to base my work on quality principles. Quality can be described as a value, like ethics, even though that is not the strict definition of the word. How can I, as a technical communicator, uphold quality as a value in my work and the products that I document?
If quality is one of my values, I will:
-
Do my best to ensure that what I write is true.
-
Ensure the product is represented accurately.
-
Understand, thoroughly, what I am writing about.
-
Validate, to the best of my ability, that the the documentation portrays how the product actually works.
Working in a software development environment means time-to-market is king, and most teams have very aggressive schedules in which to program, test, and release software products. That leaves little room for an SME (jargon: subject matter expert) to answer questions and to review my work.
What to do?
Experience has provided a constellation of tactics to choose from:
-
Reviewing the requirements thoroughly, and keeping track of which ones have been implemented and which ones have not been. The project manager can help with this.
-
Reading and matching the design documents to the product and documentation and reconciling the differences. The reconciliation can be used as a basis for discussion or a checklist with the SMEs.
-
Get access to, and use, the software. Insist on it. Become an expert in what the software does, and what problems it solves for your customers (yes, they are your customers).
-
Make friends with the QA testers. They know what works, what is under revision, and where the original requirements may have changed.
- Offer to record the defects in whatever tracking system the team is using, if you don’t have a formal QA department. You see the software evolve in real time with this task.
- Make friends with the developers. If you can sit in their area, do it! Participate in the development meetings. Bring food. Offer to help with writing and editing error messages.
- Make your questions concise and to the point. Offer lists of “yes” and “no” statements to your busiest SMEs and allow them to “check” the correct answer.
- Have “provide an answer” contests, where the first person to provide the review copy, or answer a question, gets a prize (cookies to order, lunch on you, Nerf basketball, and so on.) This one depends on your environment. This may not be appropriate for a team at a financial company, but could be great at an informal Dot com.
- And last, but not least, put yourself in their shoes and work with the schedule as much as you can.
Technical communication is a service-based occupation; my job is to provide a service. First, I am an advocate for the user (discussed in another post). Second, it’s a requirement to provide accurate, easy to use instructions (or other materials) to make someone’s work better, their lives easier, or add some other benefit related to the product or service documented. Third, to save money in tech support costs for the other customer–the company I work for–by providing users’ with answers (up front) they can use.
So, to me, quality is a value.
+=+=+=+=+=+=
| qual-i-ty - noun.Character with respect to fineness, or grade of excellence: food of poor quality; silks of fine quality. High grade; superiority; excellence; an essential or distinctive characteristic, property, or attribute.Citations: From Dictionary.com
American Psychological Association (APA):
|
Nice post.
Since quality is a relative concept, it seems useful to look at it in terms of the user’s experience of quality. After all, documentation is about making a product easy to use, read, understand and experience.
So we have to step into the end user’s shoes.
If we can’t access the user directly to test the documentation, then we have to use surrogates. One of those surrogates is your own imagination: imagine being individuals within a range of users, from the least capable to the most.
Maybe the ability to do that that is one of the reasons why good tech writers are craftsmen and artists, as well as technicians. We need to have a sense of the end user’s experience.
Our communication skills must be informed and guided by that “sense of others”—empathy.
By: timmantyla on June 6, 2008
at 4:43 pm