I wonder if there’s a tech writer out there—in the software industry, anyway—who would argue that being involved in the design stages of a project is a bad thing.

This theme comes up time and again among our User Education team members. Yesterday, one of us gave a presentation to our community of practice about usable design, what makes something usable, and how tech writers can contribute. She suggested we come up with some metrics that help us demonstrate how our contribution to usable design increases user productivity and lowers cost.

As part of her illustration, she showed a chart about the more and more expensive it gets to fix a bug from the requirements stage through to the maintenance stage.

An idea came to mind, and I shared it with the team, that one of the things that we can use some hard numbers with is determining how many steps it takes to complete a task. The presenter had used an example to show how a process that she would have expected to take four steps instead took twelve. If we can analyze designs and determine how many steps it takes to complete associated tasks, we can tell the project team, “That’s going to be hard to explain. That process will take ten steps (or fourteen, or twenty). And when a user sees a procedure with that many steps, the first thought is ‘This is going to be hard,’ probably followed up with ‘I hope I do it right.’ Confidence goes into a nosedive.”

› Continue reading…

Bookmark It

Hide Sites

Last week I visited the pilot location for Project Pinnacle. My focus was to see how well my first-draft quick reference guides worked, but I spent some time training.

The office staff tended to want to ask me how to do things and be walked through it, but I took those times to ask them to test out the instructions for me. However, on one occasion, I had to guide a brand-new user through a somewhat complicated scheduling procedure while she was on the phone with the person setting up the appointment. I figured it would be better to help her through that one because she’d feel enough pressure from trying to do it right and in a timely manner.

In addition to notes on improvements to make to the guides, I kept other notes. The rundown:

• 5 tasks to add to the guides
• 14 other changes needed to the guides
• 20 feature or change requests
• 10 bugs
• 14 miscellaneous items that were questions, observations, or usability problems

› Continue reading…

Bookmark It

Hide Sites

That word has reared its ugly head again.

A recent post by Ellis Pratt on the Cherryleaf blog discussed David Black’s claim at the TCUK 2010 conference that someday, end-user documentation won’t be needed. Ellis says:

Although he felt no-one but Technical Authors had the answers to how to understand complexity and failure, he believed that products would become so intuitive, and people would be so technically adept, that there would be no need in the future for end-user documentation.

Other than the fact that I think it’s a bit tacky to respond to an invitation to speak at a tech comm conference by telling all the attendees they’ll be obsolete in a few years, I have a problem with this fallacy that anything, especially technical in nature, is intuitive. I’ve heard the word intuitive in this context so often that I’ve come to almost despise it.

It’s something of a cliche to consult the dictionary when trying to prove a point, but in this case, it’s highly called for. Dictionary.com says, and I quote, intuitive is “perceiving by intuition, as a person or the mind.” Well, nothing like using the word to define the word, so here’s one of the definitions of intuition: “direct perception of truth, fact, etc., independent of any reasoning process; immediate apprehension.” The next few definitions are similar. Then we get the definitions according to the school of philosophy:

a. an immediate cognition of an object not inferred or determined by a previous cognition of the same object.
b. any object or truth so discerned.
c. pure, untaught, noninferential knowledge.

Note that part of this definition are the concepts of no previous knowledge and being untaught. The other definitions hint at these concepts, but the philosophy definition calls them out specifically.

I continue to argue that very little in life is truly intuitive. The idea that we can fabricate and invent things that are in some way intuitive is a myth. I’ve had this cemented in my mind even more through recent experience.

› Continue reading…

Bookmark It

Hide Sites

In our ongoing department reorganization, we technical writers are experiencing some angst as we carve out a desirable place for ourselves. However, as we’ve talked about it as a community of practice (no longer as an organized team with our own manager), I think we’re coming to an agreement that now is the time to make things happen—to strike, as Tom likes to say.

After the initial, high-level reorganization, Tom and I are in the same division, so we’ve discussed a plan for taking a more prominent place in project managers’ and interaction designers’ consciousness. This is the key for us because the PMs are the ones to include us in their project plans and budgets, and we would be working with designers to decide on user education approaches and contribute to the design itself.

Finding Tech Comm’s Place in the Family

After Tom’s blog post about our meeting with an interaction design manager, I asked him about his point of view and his readers’ reactions to the post. We discussed getting involved in projects early and contributing to user interface text. We talked more about this in our community meeting this week. Again, we’re looking to make sure that the people who make the decisions give us a rightful place at the table.

We also talked about many designers’ “holy grail” of creating products so intuitive that no documentation is needed. Tom reminded me and then the group of an important point I had forgotten. An interaction designer once said something like this to me, and I had passed it on to the team: “Saying that ‘if the interaction designer does his job right, the product doesn’t need help’ is like saying ‘if the developer does his job right, the product doesn’t need QA.’”

› Continue reading…

Bookmark It

Hide Sites

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’s Don’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.

› Continue reading…

Bookmark It

Hide Sites

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.

› Continue reading…

Bookmark It

Hide Sites

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?

› Continue reading…

Bookmark It

Hide Sites

I saw an unintentional exercise in usability while sitting in an STC Summit education session on Tuesday in the Hyatt Regency hotel. It’s expected conference behavior, at least at STC conferences, that if you decide within the first 15 minutes that a session isn’t what you expected or that it won’t meet your needs, you can get up and go to a different one. I was sitting at the left end of one row near the door and watched a couple of people leave this particular session, and each person’s interaction with the closed door was not optimal.

Some of the session rooms were set up using relocatable walls. The doors in the walls were designed, I assume, to not take up any more space on the Z axis than the rest of the wall to make storage more tidy. This means that the person who designed the latch mechanism had to figure out an alternative to a knob or handle.

The result was a three-inch-wide button with the word PUSH printed three times around its perimeter (see the photo). You disengage the latch mechanism by pushing the button.

Whatever it accomplished, this design didn’t really meet people’s needs, or at least it didn’t meet conventions so that most people would understand how to use it.

› Continue reading…

Bookmark It

Hide Sites

Blogger’s note: A few months after starting my blog, I thought about doing a series of slightly animated videos about me interviewing Gryp, a cartoon gryphon. I based the gryphon image on my site on that idea. Here’s that first interview with Gryp (only slightly edited for this posting). Who knows, maybe there will be more of this in the future.

Ben: Today’s discussion is with Gryp. He’s a gryphon. You don’t see them every day. So, Gryp, just what does a gryphon have to do with technical communication? Is there a connection, or are we just chasing shadows and pixies?

Gryp: I like chasing shadows and pixies. So we can take this in a whole different direction if you want.

Ben: Just answer the question.

Gryp: All right. Take a look at me, and after you’re done admiring my majestically good looks, you’ll notice that I’m half eagle, half lion. You geneticists out there, don’t overanalyze what you see—I am a mythological creature.

Wait… I just realized that raises all kinds of questions about the fact that I’m here right now. But if you want to chase that pixie, find a philosophy blog or a copy of Hamlet’s “to be or not to be” soliloquy.

Anyway, I think you technical communicators usually combine different roles in your work. You’re not just one thing or the other. You’re a writer one hour, an editor the next, then a trainer. The next day, you’re giving input on interaction design and talking about usability. You may be a manager on top of all that.

Ben: So what you’re saying is that a gryphon resembles a technical writer because there is a blending of identities. Do you think that being parts of different things makes you less of each of those things? You’re not entirely a lion, and you’re not entirely an eagle.

Gryp: It doesn’t have to mean that. I’m versatile.

Ben: How so?

Gryp: I can catch prey by chasing it down or dive-bombing it from the air. For you technical communicators, substitute “developer” or “subject matter expert” for prey, and you can see my point.

Ben: Most developers or subject-matter experts would rather not be dive-bombed.

Gryp: Have you ever tried it?

Ben: Can’t say that I have.

Gryp: Shows what you know. Look, you can be very good at the various roles you perform. Some could be minor roles, but others you perform every day. The more versatile you are, the more value you have.

Ben: I have to admit, this blog wouldn’t be the same without you. [To the audience] Thanks for tuning in and listening to a gryphon’s thoughts on technical communication. I’m sure you will never be the same. Until next time!

Bookmark It

Hide Sites

I recently held some informal usability testing for some changes to an online help system I was considering. Because I hadn’t done any testing on the original help, I incorporated some of that as well. Doing so pretty much confirmed that I was on the right track with the changes I wanted to make. The help as it stood wasn’t very usable.

All documentation can stand some usability testing. We technical communicators like to claim that we’re user focused and user advocates. I like to believe that myself. However, sometimes we can be more like developers than we want to admit. We do things our way, the way we think is best. We may have even proved in the past that what we’re doing is pretty user-friendly. But times—and users—change.

› Continue reading…

Bookmark It

Hide Sites