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.
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.