Journals by RSS
Journals by EmailThis month we’re transitioning from an old custom document generation application to a new one. Having been the person responsible for training a small group of users, I spent much of yesterday with the person upon whom falls many of the weekly tasks. The project team and our customers wanted to be sure that she’s ready to go when we’re live with the new application and the old one is turned off. (The old one is connected to a legacy database that will be retired soon, so it won’t be available as a backup for very long.)
As we went through the document generation process, this particular user—let’s call her Melissa—let me know where she wasn’t clear on one thing or another. Particularly, she wasn’t clear on what were the exact differences between each of the three screens that the process involves. As we got to the end and Melissa still seemed a little fuzzy, I asked, “Would it be helpful to have a one-page guide that walks through the three basic steps?”
Now, there is a help system. I even have a topic that covers this process from start to finish, involving about ten main steps. However, I could suddenly visualize a page where I matched three steps (with a few substeps each) with the three screens. But the approach here was to give the instructions in their most basic form and leave out a bunch of the details.
“Yes, that would be helpful,” Melissa said.
So I took a couple of hours today and put one together. I sent it off at the end of the day, so I’ll see soon what feedback Melissa and her manager have.
What a Girl (or Guy) Wants—in User Assistance
Because of this, I thought about why it’s important to talk to the users of a product before deciding what kind of documentation to deliver. In the case of this application, it’s used by a very specific group of local employees, and I had ready access to them. But a help system was requested at the start of the project, so that’s what I put together. Though I have a good relationship with the involved manager and customers, this may have been a case of crossing off a checklist item. Similar to the first project I worked on at this organization, the business analyst had an idea of what documentation deliverables the project should include. This isn’t a particularly bad thing, but I think this analyst likes plenty of user documentation. We ended up dropping the manual and tutorial ideas.
We could save some time and money by interviewing users at the beginning and finding out how they like to get help. I did ask a few people early on in the project, but one person likes videos, another likes one-page guides, and yet another doesn’t use any kind of help at all and asks co-workers instead. But by that time, I’d already started the help system, and I suppose it was just as good an answer to a lack of consensus as anything else.
I normally wouldn’t respond to a one-off request for some user assistance deliverable, but in this case, I had this idea jump into my head, and it took me two or three hours total. And when a lot rides on one person’s shoulders, I thought it important to cater a bit to her needs.
Early Analysis and Usability Testing
In general, though, this is one of the reasons that early audience analysis is important. Early usability testing is important as well, even if it’s done with a low-fidelity experience like paper and sticky notes. When the technical writer watches users go through designs, he can get a picture of what kind of user assistance would be helpful for the users. The usability team could even find a way to incorporate that into the testing, such as inserting a help option or other links to see what users do when they get stuck.
Unfortunately, usability testing gets a place even behind technical writing in the teams I’ve worked on. Most of the time, at least. I can count on one hand the number of times (I’m aware of) that an interaction designer has gone through sessions with users where they work through prototypes or other designs. But if I can see how users work through application screens and hear their questions, like I did today, I’ll get a better sense of how to present effective assistance. These general insights would hold true even if the design changes based on the testing.
With talk in the field about branching out so you’re not just a technical communicator, maybe I need to coordinate with interaction designers more to set up usability testing early in design cycles. Then I could become something of a usability consultant.
Related posts (auto-generated):
Ben Reply:
April 23rd, 2010 at 3:55 pm
I don’t know how many marketers make the connection between usability and sales. Sometimes people think they have such a great idea that they don’t need to do any research, everyone will love their product, and all they need is good salespeople. I agree that product managers should care about usability and advocate it. But I think the reason technical communicators should care about it is that it directly impacts our work. The less usable a product is, the harder it is to provide good documentation and training. I don’t think we’ll see the day when the whole human race understands all technology so well that the need for documentation and training disappears, so we won’t put ourselves out of a job by pushing for usability testing.