Publicious

There are many ways to train people to use complicated new software. You could sit down with each new user individually and show them what to do. Because you have 300 people on staff full-time to do that. The training might be a live demo of some of the processes, or one of those movies. It could be a series of online modules that take the user through various steps of various workflows. There might be a quiz at the end. Everybody likes quizzes.

We chose a variety of training approaches. This is a nice way of saying we didn’t really have a coordinated training approach. Our training started out with the best of intentions, of course. Unfortunately, our system was pressed into service before it was really finished, so the training program was REALLY not really finished.

Our first attempts at training involved the time-honored “live demo in front of a group of people” technique. I wonder if there’s anything more useless. Imagine a group of 20 people who don’t really know what’s going on, in a darkened room, staring at a projection of a completely foreign UI, listening to some dork (me) droning on about “tagging” and “attributes” and whatnot. For an hour. And at the end, being told to go back to their desks, and the software would be installed within the next couple weeks, and there are no handouts or manuals, but when you get the software, start using it all day as this is now your new way of working. We didn’t even offer snacks.

So that having predictably failed to impart all the vital skills they needed, the next step was to sit down with them individually or in very small groups and, with one of the users driving, talk them through the tasks they needed to do. “Click on the File menu . . . no, the Documentum file menu, not the Netscape file menu . . . good!” This actually worked pretty well. The only downside is the “trainer” has to spend all day doing it. And the trainer is never really “the trainer”, they’re more like the project manager who’s dropping everything to train people as they have questions.

To try to organize the random training and ensure that everybody in the group was getting the same information, we decided to hold weekly meetings to go over any questions that came up. Emergencies would still be handled as they occured (an emergency being an “I can’t do any work until you explain to me how to do this” situation). Unfortunately, or maybe inevitably, no questions ever came up in these meetings. I’m not kidding. “So how’s everything going?” “Fine.” Then an hour later 15 phone calls come in asking for individual help.

Then there’s the problem of “rogue training.” There’s always somebody who kind of gets it, assumes they totally get it, then trains their colleagues on their own. It is, after all, easier to ask the person sitting next to you than calling the person who caused all this pain and inconvenience in the first place. This caused no end of issues for everyone involved. Someone determined a simple 35-step procedure for creating a page and printing it out for further editing. The problem: the same thing could be accomplished in 3 steps, which had of course been covered in the original dark-room demo, but everybody forgot about that. And even better, the page didn’t really need to be printed out every time as it was after all a PDF file which could be viewed onscreen. But that rogue trainer had shown everyone their technique, everybody started doing it, and hours upon hours were wasted waiting for pages to process and print. And even after we discovered this and showed everyone the “right” way, many people still did it the “old” way because that’s what they were comfortable with.

(We also had someone come up with “rogue documentation” which was presented to me at a project postmortem. “Look at how complicated it is to use this!” “Where did you get this documentation?” “I wrote it up myself because this is so hard I needed a cheat sheet.” “I understand your frustration. I wish you would have talked to me during the project because most of this could have been done differently which would have made it easier.” ” . . . “)

When it finally became obvious that our ad hoc training program wasn’t going to cut it, we assigned someone to be a trainier and come up with a hands-on training program. And it wasn’t me. That was one of the happiest days of my career. It was one of the users, who knew what the users were going through, and spoke their language, and had credibility within their ranks. O joy! I just peeked in on the first couple sessions to make sure they weren’t talking crazy talk. And they weren’t. And everything went pretty smoothly from then on. Imagine that.

So let’s say the stars align and your child’s unicorn is delivered on time, and you actually do have a dedicated documentation writer and training developer on your project. What kind of documentation works best?

I suppose everybody prefers something slightly different. (I personally would love to see the “kinesthetic” documentation for an XML workflow. “Aural” would be cool too.) Most of the time, though, documentation is going to be a fat binder with page after page of text and screenshots, or something online with similar text and pictures linked together in some fancy way.

I feel that you need to have several kinds of documentation available to users. For our content model, we created a very detailed catalogue of all the XML elements and attributes, with tree models to show how the parent/child relationships worked, and output screenshots to show what the XML tagged content would look like “on the page”. I thought it was very thorough yet concise at a mere 300 pages. The users thought it looked like “stereo instructions” and didn’t find it helpful at all. I guess the fact that I helped develop the content model, so I pretty much knew it backward and forward to begin with, clouded my judgment of the catalogue’s usefulness.

So based on that epic fail, we created a booklet of “quick topics” that featured lists of steps in various procedures. Need to know how to import an art file? Here’s the step-by-step instructions. Some of them even had screenshots to show what menus to choose or buttons to click. These were slightly more useful than the catalogue, but most of them had 20 steps or more—the steps add up when you make “click on the OK button” its own step. And there are 12 instances of that in a particular process. (Maybe our processes were too complex? A topic for another time perhaps.)

We also had a design catalogue of the various styles available. This actually was helpful as authors and editors developed the concept for certain kinds of pages. When there are 14 different styles available for questions, it’s nice to have a picture of what they all look like. But even this was limited. They had to look in the catalogue to match the design to the XML that was behind it. And they already didn’t like the catalogue because it was too confusing.

I think our main failure was to organize the documentation and training around how the system worked, not how the users would work. A chart of elements and attributes is pretty useless when you don’t know what any of the elements and attributes are for in the first place. Describing steps in using software in terms of the software rather than in terms of your user’s workflow and tasks is also less than helpful. I’m not “uploading a binary object into the docbase”, I’m “putting the picture of George Washington into the system so I can put it on this page.” I’m not “editing formatting attributes for composition”, I’m “making this paragraph be in 2 columns so it fits right.”

For our new attempt at an XML workflow, I hope we can develop documentation that’s short, uses language familiar to users, and is well indexed so it’s easy to find everything. Ideally it would be available online in a help menu within the interface itself. I wouldn’t go so far as to want that stupid talking paperclip thing that interrupts you when you’re typing, but some contextual help would be very cool. We should still have exhaustive catalogues of our elements and attributes, but those would be for the technical people working behind the scenes.

I wrote a post awhile back where I confessed to my ineptitude with drawing. I said no amount of training would allow me to be an artist because I don’t have the brain upgrade required to transform 3D reality onto a 2D piece of paper. I still believe this is true, but there’s a problem I didn’t consider. What if my boss showed up one day and said 20% of my job now entailed drawing pictures? Do I quit? Take a 20% pay cut? In this economy? My only choice would be to try my best to figure out how to do it.

The same goes for authors and editors who work for companies that are implementing XML workflows. Yes, they were hired for their writing and editing skills. But as technology progresses, so do our jobs. We all figured out how to use computers when they came along. I’m sure some people are still more comfortable with a legal pad and pencil or an IBM Selectric, but their job requires using new equipment, which requires new skills.

Depending on where you work, training is either a fully-supported discipline with dedicated professionals whose only job is to make sure you know what you’re supposed to be doing, or you work someplace where they throw you a manual and a typed-up “tip sheet” that some guy put together in his spare time 3 years ago and you’re pretty much on your own. And of course there are shades of gray in between.

Our XML publishing system had a hodgepodge of approaches for training. We had the professional manuals created by Arbortext and Documentum for their products. We even had an Arbortext trainer come in to “train the trainers”. A caution about that: if you assume you’re training trainers, then you need to make sure part of their job description now includes training, or you’ll end up with a couple people who know what to do spending odd moments tutoring others as they have time. This is not exactly a rigorous approach.

But because there’s nothing in the Arbortext or Documentum manuals that actually explains how WE were using those products, we needed to create our own documentation. The manuals might show how to log in, but they don’t say what to do after that. At the beginning, we actually had a training department. I met with the person assigned to the project and explained how it was all going to work. She took screenshots and wrote up some procedures. Then there was a merger or something and that department was disbanded. So we had a 15-page Word doc with about a quarter of the procedures we needed documented.

Which brings up another point: if you’re working on a complex project that’s going to fundamentally alter how people are going to do their jobs, and training and documentation are not part of your project plan, then you’re asking for trouble. The kind of trouble where you have a roomful of people showing up tomorrow to learn their new tasks and you have nothing to give them.

And, of course, that’s exactly what happened with us. It almost felt like a form of abuse when we had a group of editors watching me click through their whole new world, and there wasn’t even a handout to give them at the end. I’m sure you can imagine the number of calls I fielded when they finally started working in the system. And the enormous frustration they all felt. Toward me. Awkward.

So what’s the big deal, you might be saying. Write something. Annotate screenshots. Whoop-de-doo. And I agree. It shouldn’t be that big a deal to do this. What is the big deal is doing it at the same time the project is being developed. It’s hard to do use cases and testing and bug reporting at the same time as crafting easy-to-understand documentation and training modules. There’s only so much time in the day.

It would therefore be ideal if at least one person on the project was responsible for documentation and training. And they should be there from the beginning, so they understand all the little details and workarounds that inevitably crop up during development. When the project goes live, so should the documentation and training program. And the documentation and training should be constantly revised as new features come on line or new processes are discovered as the system is put through real use.

Also unicorns should be assigned to every child under 12 and my car should run on wishes. But we can dream, can’t we?