A Mini-Workshop: Grassroots Documentation Testing

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.

Everything is Minimalism

Don’t Hate the Webinar

I am training coordinator for our team, which means I look for trainings we can attend or develop and help keep them documented. I have always been partial to webinars—get a little info, stir the mental pot, all while sitting on your butt when you could be parsing release notes–but these days I don’t book so many of them for the team. Our group has a way of reducing every webinar to something they already know.

Is it because many of the presentations cover the topics at a high level and we’re becoming advanced? Is it because webinars are a passive learning experience? My team lead handed me back an Intercom article I’d loaned him recently, saying, “So, basically, be more visible in the company.”

Each time this happens, I have the sensation of tilting a prism, or looking through someone else’s prescription glasses. “Oh, crap. Everyone in tech comm really is repeating themselves. And repeating everyone else’s stuff, too.”

I don’t really think that, though. I think that it’s just that the principles of good writing don’t change, nor do the principles of project management, nor of team building, nor of promoting your team within the organization.

As we advance in our field, we can’t expect to read books and attend trainings and have them be packed from start to finish with brand new, actionable information that we’ve never heard before. Articles and webinars can give us a new idea, reinforce a nuance, or energize us. We have to make it an active learning experience.

Eight Webinars on Minimalism (with Homework)

This week and next week I am attending an STC certificate course on minimalism, taught by Bernard Aschwanden of Publishing Smarter. Bernard started off with a discussion about the definition and characteristics of minimalism. He’s also emphasizing audience analysis and improving the actual products.

These are all webinar topics in themselves, and webinars I’ve attended, at that. But talking about them all together, in the context of minimalism, set things clicking in my head.

And Now I Will Perform a Magic Trick

Partly based on Bernard’s information, I’m putting together a training for our team on what minimalism means to us. We’ll talk about definitions, but then we’ll talk about how our current initiatives support minimalism and what minimalism can do for us.

1.Knowing our audience.

We’re gaining momentum on this, and we should be more deliberate about it. We can’t successfully reduce the volume of our content—which is currently overwhelming—without a good idea of where we can focus. We should identify our critical users and write to them. If we’re fuzzy on this we’ll be veering all over the place with our documentation.

2.Improving the product by improving our communication with the developers.

The idea is that if the product is intuitive, we’ll need less documentation. No one on our team, that I know of, has formal UI design experience. What we have is a honed sense for identifying and clarifying inconsistencies and processes.

For a software application, we could apply that to terminology, labels, organization, and even workflow. Our team has tried several approaches for giving input on our products, but none of them are likely to work until we are on better working terms with the development teams. We should talk about how to do that.

3.Articulating our value as a business asset.

Everything is easier when your work is valued. Our manager works on this all the time, and it gets better for us all the time. How can we be deliberate about supporting this effort?

Result: Everything is Minimalism. Discuss.

So minimalism is pretty much related to everything we’re doing right now. It’s the goal we’re aiming for. The three areas of focus above have been areas of focus for a while, but now I have a more clear vision of what the desired outcome is—minimalism. Documentation that gives the clients the information they need, when they need it. “And no more,” as Bernard says.

I’m excited to have a training topic that will be a snap to put together. As much as possible, trainings should meet the team where they’re at. Maybe discussions are where we’re at. There’s plenty to talk about, at least.