My presentation proposal for the STC 2011 Summit was accepted! It’s a mini-workshop in the Usability track called “Grassroots Documentation Testing.” I just got the email from Lloyd Tucker, STC’s Deputy Executive Director. I’ve mostly interacted with Lloyd over email, but he’s so thoroughly pleasant that it’s especially enjoyable to get a congratulations from him.
So, yay.
I’ll be leading an exercise and a discussion, and I’ll follow up with a blog post to summarize our ideas.
For the exercise portion, we’ll practice writing scenarios to test user assistance content on hypothetical co-workers. Then we’ll have a brainstorming session to share success stories and discuss solutions for the most critical challenges to do-it-yourself documentation testing.
Hats tipping all over the place to Steve Krug and Tom Johnson.
When I got a copy of Rocket Surgery Made Easy by Steve Krug, our tech comm department adapted Krug’s do-it-yourself website testing method to test documentation, with an important variable–we tested on co-workers. The resulting benefits were not the ones I expected, nor were the challenges quite the same as the ones covered in Krug’s book.
The reading I’ve done as a novice helps me justify the “why” for testing. Now I want to provide a forum to discuss the “how.”
This discussion is an opportunity to supplement the expert resources on usability with some grassroots collaboration. I’m not an expert, but as a group, we’ll work through an exercise to demonstrate some challenges, then discuss solutions for the most severe issues; a debriefing à la Krug. After the Summit, I’ll blog our group solutions. (This part of the session was inspired by Tom Johnson’s collaborative posts over at IdRatherBeWriting.com.)
I think this will resonate with tech writers and usability novices who need to overcome some obstacles and start somewhere with testing.
Sometimes technical communicators come into a department that has established formats and standards, and it can be difficult to find a point of entry for improving upon those. Or, basic audience analysis may be lacking from a tech comm department’s processes and body of knowledge. In some environments (and also depending on one’s experience level), it can be difficult to make the case for professional usability testing, or for direct access to users. Employers may be more open to low-budget, internal testing.
I’m expecting this to interest creators of users assistance who are already testing their docs or those who want to know how to get started. I expect a mix experience levels in the tech comm field.
What I’m hoping to accomplish:
Otherwise known as the “key learning objectives” part of the session proposal.
- Gain awareness of the process and challenges of writing test scenarios for user assistance
- Gain awareness of what is working and not working for our colleagues
- Increased confidence in the ability to test our content
- Increased proficiency in using collaboration as a problem-solving tool
- Produce a list of solutions that can be shared with the STC community
Hooray! Also, feedback.
What would attract you to this session? What would make you skip it? Do you have any tips on presenting? Do you have a testing story? Please share down in the comments area.
This sounds like a very good practical session. I’m all for the “how” sessions instead of the “why” ones. I think documentation (and website testing) is very important, even if you can only do it on your coworkers (as is my situation). I wish I could go to the Summit this year and attend all the cool sessions. I’m looking forward to your follow-up post. Good luck — and have fun!
Thanks, Christina. Would you be willing to share a bit more here about how you test docs on coworkers?
Well, it really depends on the document. For instance, at one job I created a PDF form that had a Submit button. I asked a few coworkers to try it out on their Adobe Readers, to 1) make sure it actually worked and 2) get any design/usability feedback. I didn’t ask any specific questions; I just wanted their organic feedback since they were the intended audience. It really helped, too, because one person said “The Submit button should be on the bottom of the second page, not on the top.” I dunno why I put the button at the top, but it was a good catch by my coworker.
At my current job, I’ll ask some structured questions like, “Are these boxes big/long enough for you to write in?” and “Does this hierarchical numbering help or hinder you while you perform the steps?” and, for marketing materials, “Which color/size combination is more appealing?” Finally, I ask people to proofread because I make all kinds of typos I don’t catch til much later.
In essence, I like to gather un-constrained, first-thought feedback because generally they catch stuff I can’t see or didn’t think about. User testing, even with co-workers who may not be part of the intended audience, is very helpful for solo writers like me who have no resources otherwise.
Hope that helps!