Gryphon Mountain is the online home of Ben Minson—technical communicator, writer, and cartoonist. This blog discusses tech comm and other writing topics. More »
Monday, August 9th, 2010 | Guest Posts | Comments Off
Guest post by Kristi Leach.
So, You Need a Book about Usability
A while back, I asked Karen Bachmann, a usability expert in our STC chapter, to recommend some books for our tech comm department. I was looking for a place to start with the topic. Without hesitation, she told me everyone should read Steve Krug’sDon’t Make Me Think.
So, I ordered both Krug’s books: Don’t Make Me Think and Rocket Surgery Made Easy. Rocket Surgery is an expansion on his explanation of how to do simple, cheap usability testing. It comes with great check lists and sample scripts that you can download, along with a free chapter of the book and recommendations on equipment.
Once I had read Don’t Make Me Think, I wanted to send recommendations to our developers. That seemed like an overwhelming undertaking, so instead, after reading Rocket Surgery, I decided to implement a testing schedule for our documentation, with the long-term goal of getting to test our products.
I knew from the email subject line that I wasn’t going to like what was in the message.
The subject contained the name of an application, then two frightening words: “help sheets.”
I’ve found that outside the tech comm profession, people tend to throw around terms like “help” and “tips” without really thinking about what they mean. That’s why I felt a bit of dread as I opened this particular email.
The Rogue Documents
Looking for feedback, the product manager had forwarded two Word documents from an instructor who teaches this particular application as part of a week-long training for office staff. The instructor had documented a couple of end-to-end processes that weren’t strung together like that in the help.
Let’s just say that these documents weren’t done by a professional tech writer. I didn’t even get down to giving feedback on a content level; a subject-matter expert did some of that. Instead, I was concerned that by giving these documents to the class members, we were providing an inconsistent and less-than-professional experience.
I was also concerned because these documents’ pages were numbered 35 through 41. So what else was there that we didn’t know about? How much effort was being duplicated? Since it’s my full-time job to create such materials, I would have preferred if the instructors let us know about the need and asked me to fill it. Frankly, it felt a bit threatening, as if I thought my job was in danger. I considered this “rogue,” or unofficial, documentation.
The Idea
I ignored this email until the next day. Then, however, I decided to change my stance. I realized this was an opportunity, not a slap in the face.
In today’s world of technology changing in the blink of an eye, ongoing professional development isn’t an option for technical communicators, it’s a requirement. Over the past decade the field of technical communication has grown and gained more respect as a legitimate profession, and the complexities of the job and skill base required of technical communicators have also increased. Some of what’s new we can learn on the job—if we have a job—but sometimes we need to obtain the skills to stay vital in other ways.
When it comes to professional development in tech comm there are a lot of options. If you’re gainfully employed, enjoying what you do, and just need to brush up on the latest tool, then probably just a training seminar or a short online class is all you need. But if you’re not employed, or employed in a different capacity than you’d like to be, then you might want to consider a bigger educational commitment to make yourself more marketable as a technical communicator in today’s world.
In 2008 I stepped out of the working world to go back to school to earn my master’s degree in technical communication. While I’d started my career as a technical writer in a software development environment, I’d changed roles along the way, and by 2008 I was wondering how I’d gotten on the train I was on and, more importantly, how I could get off of it. I decided earning an advanced degree was the right decision for me, so in January, 2009, I took the plunge and started graduate school as a full-time student.
Tuesday, July 27th, 2010 | Uncategorized | 2 Comments
One day I spent much of my time with a person who was new to a desktop application I work on. I provided documentation for the application, but this particular person—I’ll call her Ann—tends to doubt her ability to learn. So I was happy to work with Ann one-on-one to help her learn the steps of a procedure she would use at least weekly (and that she knows well at this point, I’m happy to report).
As we talked, Ann decided to open a new Word document to work in. I watched as she went into her file system and located a document with the file name “blank page.docx.” She double-clicked it to begin a new document.
I was somewhat surprised and even a little amused.
I started my current job five years ago this week. Reaching the level of senior technical writer brings me to ask whether I’ve got the smarts to go along with the time I’ve clocked.
A Narrow View of Tech Comm
When I graduated from Utah State University two months before starting as an intern, I thought technical communication consisted mainly of writing manuals, help systems, and the occasional tutorial. I thought the main activities were writing and creating images for print or Web.
My definition of a technical writer didn’t differ much from most people’s if at all.
I hadn’t heard the terms CSS, single sourcing, structured authoring, DITA, social media, Agile, RSS, SEO, or content strategy. Some of these things were either relatively new or not dreamed of at that point.
I belonged to the student chapter of the Society for Technical Communication, but the chapter members mainly learned from each other. There was only so far we could go that way.
In technical communication circles, we sometimes take ourselves on snipe hunts. Our quarry: getting people to read our documentation.
How do we design it to be attractive? How do we write in a friendly and compelling voice? How can our diagrams be more interesting? How can we turn our documentation into entertainment?
A More Relevant Question
I think we’re past the point of no return in this area. People will read if they want to, but they generally don’t want to read documentation. (Unless maybe you’re including an engaging back story in the manual for your computer game or providing documentation for open source developers so they can be productive in their volunteer efforts.)
This isn’t to say that the questions I asked earlier aren’t important. Nevertheless, I think they’re secondary to the real question.
How do I write for someone who will spare near-zero attention for my material?
Wednesday, June 23rd, 2010 | Uncategorized | Comments Off
Tech writers enjoy—in a schadenfreude-ish way—stories about problems that result from users’ confusion about using a product, especially when the problems are monumental. We love those examples because they typically illustrate how good user assistance would have saved the day.
Some examples aren’t so dramatic, such as one I ran across a couple of weeks ago. I was working in a test version of one of the software applications I work on. This environment has data copied regularly from the production version because of the complexity of the system, so as a result, we may see what the users have recently done (though the information is always a week or two out of date) while we’re doing our own work.
This system includes a feature called “custom fields.” Using this feature, users can add input boxes to certain screens to track information that’s not already set up to be tracked. This helps them meet the individual needs of the offices they work in. When adding a custom field, a user specifies a field label.
In this test environment for a particular office, when looking at the screen where custom fields are set up, I saw only one custom field had been created.
Ben: Welcome to our second installment of Interview with a Gryphon. Today, Gryp and I are discussing a subject that has a lot of technical communicators enthusiastically speaking up.
Gryp: You mean how that Sauron guy forged one HAT to rule them all?
Ben: You’re getting a few universes confused here.
Gryp: Me? You’re the one talking to a mythological creature.
Ben:*Ahem!* We’re going to talk about a discussion about the Society for Technical Communication that was started by Kristi Leach and carried on by Sarah O’Keefe and numerous others in comments on their posts.
Gryp: Wow, links within your dialogue. That’s pretty slick.
Ben: If you’re good, some day I’ll teach you how. So Gryp, the discussion is largely about old ways versus new ways of doing things. For example, big central conferences versus smaller conferences or unconferences with more open formats. Or top-down leadership and formal structure versus online communities and more volunteers. Would you like to comment on what you think about STC’s current state in this area and their efforts to make changes?
Thursday, May 13th, 2010 | Uncategorized | 2 Comments
A couple of weeks ago, I approached one of the project managers I work with about conducting usability testing on that project. This is an application that is used in hundreds of offices around the world, and we frequently receive enhancement requests via the feedback option provided in the software. It’s apparent that the users care about the usability of the product and about making it better. This manager suggested we bring up the subject with the interaction designer and business analyst.
We did so, and the interaction designer’s question was along the lines of “Why do you, a tech writer, want to do usability testing?” I could tell he was a bit confused.
Why would a technical communicator be interested in usability testing of the product, particularly in participating in the process?
Reason 1: It Makes My Job Easier
We tech writers care about the usability of products. The greater the degree of usability, the easier our jobs are. The less usable a product is, the harder we have to work to try holding up the weak parts with the documentation. And it doesn’t work. We don’t like frustrated users.
In his presentation at the STC Summit, usability specialist Scott Butler of OVO Studios said, “I’ve never seen documentation solve a usability problem.”
I think I hear some mental brakes squealing. What do you mean, documentation doesn’t solve usability problems?
Tom Johnson of I’d Rather Be Writing interviewed me about Don Moyer’s STC 2010 Summit presentation on using drawing in tech comm. (You may want to turn up the sound—I’m a soft-spoken kind of guy.)
Journals by RSS
Journals by Email
