TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: The Source of Bad Writing - WSJ From:Dave C <davec2468 -at- yahoo -dot- com> To:Tech Writing <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sun, 28 Sep 2014 10:16:56 -0700
In a word: test the documentation (OK, that’s 3 words…)—or video or whatever you’re producing—on a live subject.
Don’t know if Apple still does this but they used to—as part of every document’s schedule: sit a volunteer (shipping clerk, receptionist, etc.) in front of the product, put the draft in their hands and sit back and watch. The result was enlightening and a little “homer simpson-ish” (“Doh!”) when the tester would point out gaps in the writer’s understanding of the experience and abilities of the target audience. Of course you may have to cast a bit farther afield to get appropriate test subjects. When creating service materials we would “buttonhole” service technicians attending training classes at the local training center.
Our golden rule of testing: EVERY feedback comment is valid; dismiss any one at your peril. It is on this one point that prof Pinker’s entire article is hung: note all feedback and review it with other team members so no single writer’s prejudice (Pinker calls this the overconfidence in what we presume is obvious to the target audience) may result in dismissing that feedback.
One of the biggest obstacles could be getting the support of management to commit resources to make testing part of the document schedule. But simple, basic research can indicate reduced phone support and better customer loyalty (due to improved user experience) as a result of the work. How do you think Apple got such a stellar reputation for the first-time user's experience? Testing—of not just documentation but the operating system, applications, hardware (the mouse was new back then!). Volunteer test subjects were given a coupon for a dinner for 2 at a very nice local restaurant or similar thank-you gift, and another few days added to the review schedule isn’t going to break the bank.
Pinker’s premise that we as writers don’t know what we don’t know about our target audience is golden advice of which ever writer should take note. Don’t write the document alone, enlist end users of the documents (videos, etc.), let them tell us through testing what we’re missing, and present the results to the team to get outside you own “box” of presumptions about the feedback. A group effort at critical points in the document schedule can make the result reflect the target audience’s experience, not available otherwise.
Dave
(Because WSJ’s login via Facebook is all screwed up, Techwrl’ers—and not the rest of the world—get this golden advice.)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
