I just started on a new project this month. Taking the lead from Karen Mulholland‘s reporting on her Tribal Knowledge Project, I’m going to blog about how it goes.

In order to protect the innocent, or the guilty as the case may be, I’ll call it “Project Pinnacle.”

Tom, one of my User Education colleagues, was approached by a project manager he had worked with before to work on Project Pinnacle, but he didn’t have the bandwidth to take on a new documentation project. Tom asked if I could do it, so I asked him about the timeline and what deliverables were needed.

He told me a bit about it, and I decided I could take on the project. Tom forwarded me some information, including a link to a test version of the Pinnacle application and test credentials. When he let the PM know that I was picking up the project, Tom sent me an email explaining what he knew about the project to that point. Pinnacle would be used at various locations worldwide for organizing workers and their shifts and also scheduling visitors.

Tom and the PM had talked about making a set of role-based quick reference guides. He said that the application didn’t have a help link and needed one. I took this to mean that online help was an expected deliverable for the project, and I was a bit uneasy about that, especially since Tom indicated that the timeline was pretty short.

I decided that rather than jump in and start developing material, I needed to talk to the PM. I had a hard time getting a hold of him; I tried instant messaging, phone calls, and even stopping by his desk. In the meantime, the quality assurance lead had offered to give me a demo of the application, so I took him up on that.

Fortunately, Tom sits near the PM and let him know I was looking for him. He IMed me to find a good time and then called me on the phone.

My main questions were about schedule and scope, since I needed to make sure we would have the same expectations.

The PM told me that Pinnacle would be piloted in Twin Falls, Idaho five or six weeks out. He was still working out details. To my excitement, he asked if I was interested in joining him and the product manager the last two days of the week, which are the days of the heaviest traffic in that location, to observe users and see how they like to get help.

Heck yeah I’m interested, since usability is one of my interests and I also want to test out the guides I will have created by that time.

I asked about the deliverables for this pilot. We agreed on a set of quick reference guides, but I expressed my reluctance to do an online help file because I didn’t think the user demographic prefers that (and I’m not sure what demographic does prefer online help files). I was relieved when the PM said that he didn’t think a help system is a good fit for this project, either. Our users will mainly be people between the ages of 55 and 75 or 80.

So at least for the first stage, I’ll be creating four quick reference guides to be ready, at least in draft form, for the pilot in a few weeks. I’m looking forward to watching the users and seeing how well the guides measure up. It will be disappointing if what I put together doesn’t prove to be what they want and need, but I’d rather go on-site and find that out rather than prepare and distribute materials that don’t do the job.

I would have liked to be brought onto the project earlier so I had more time to work in. This is one of the reasons I want to write about how things go—it will be a way to reflect on and analyze what I’m doing and see if it’s working. Come along for the ride and feel free to offer advice on the way.

Bookmark It

Hide Sites

When deadlines are hurtling toward you with all the leniency of a runaway dump truck and you realize that you have to sacrifice something in your user education project, what do you choose to drop?

Sometimes you can even see the problem coming when you start the project. Not everything will make it, so you have to let some things fall by the wayside. Maybe it’s one of the rounds of reviews. Maybe it’s the troubleshooting section or the index. Maybe it’s the screenshots or fully colored and designed diagrams.

I confess that when I need to get the job done and I’m pushing myself to write, I feel the temptation to make the worst shortcut of all.

I’m tempted to make assumptions and trust them instead of getting off my rear or picking up the phone and asking someone, such a subject-matter expert or a user.

This is the shortcut that tech communicators can least afford to take.

Why?

› Continue reading…

Bookmark It

Hide Sites

Recently, I had some technical problems with this blog that seemed to result from a category excluder plugin. Somehow I ended up with a bunch of duplicated categories with one post assigned to each one. This was causing links to be broken and posts to somehow show up as uncategorized. Tags had also been removed.

After trying a couple of fixes to the broken links and phantom categories, I was afraid that I would have to delete all my categories and go through all 300+ posts, reassigning categories and tags. Once I found the real problem, I took the time to correctly assign posts to their original categories and delete the duplicates.

Strangely, the prospect of coming up with a new list of categories and tags and then assigning the applicable ones to each post was somewhat inviting.

Why?

If You Don’t Know Where You’re Going . . .

I realized some time ago that the categorization and tagging of my posts was pretty haphazard. I didn’t have a strategy or information architecture for my blog. If I wrote a post on something that didn’t fit in any existing category, I created a new one. If it related closely enough to an existing category that creating a new one didn’t make sense, I renamed the category (if WordPress let me) to include the new topic, such as “Web Design & CSS.” I came up with tags almost in a vacuum because I didn’t—and still don’t—have the patience to wait for WordPress’s autocomplete feature to load while I’m typing tags.

The architecture of my blog was like an untended garden, and creating an organization for my posts from scratch was tempting to me.

› Continue reading…

Bookmark It

Hide Sites

With the increasing emphasis in business on compelling content, I’ve been thinking that the field of translation may shift its focus as well.

The goal of most translation services appears to be speed, affordability, and accuracy. For example, Verbatim Solutions’ website says: “In all cases, Verbatim provides the right solution to help clients minimize costs, accelerate time to market, and ensure quality.”

But what is quality? Is it 100% fidelity to the original text?

Or is it conveying a message in a way that preserves the original intent—or even adjusts the message based on the cultures of those who speak the target language?

› Continue reading…

Bookmark It

Hide Sites

One of my fellow members of the Intermountain Chapter of STC is a major proponent of tech writers having project management skills. Planning is one of these skills.

I’ve thought for years that I’m not interested in becoming a project manager because the only writing they do is project plans. That kind of writing has held no appeal for me, and that’s probably why I’ve never seriously considered writing documentation plans before now.

Tom Johnson recently wrote about how the user education team in our organization is introducing a user education plan as part of the standard planning process for projects. He explains that he has come to support having this plan to fill out mainly because it will help him manage his time so he won’t be overwhelmed by work for various projects and then become unable to deliver quality products.

For me, the attraction of a user education planning document is to speak project managers’ language. They think in terms of budget, milestones, deadlines, requirements, and risks. A good user education or documentation plan will address these areas.

› Continue reading…

Bookmark It

Hide Sites