Education and Research SIG of STC Article
Lessons by email: quick, flexible training
As a technical writer, how do you deliver training to a large group of software developers when their work schedules do not permit disruption, and your budget for training contracts and facilities is zero?
In late 1999, my employer launched a major development initiative for our next generation product. The new product was going to increase the workload for our writers, but we would have to cope without additional staff. My response was to suggest we might accomplish this if the new interface were more intuitive to use, requiring less documentation. Consequently, I was asked to write a usability specification for the new product. In four weeks I had to become the company usability expert and provide a comprehensive specification that our software developers could understand and use.
A useless specification?
Within two days of starting this project, I realized that usability is not achieved by applying a strict set of rules, rather it is attained by adapting relevant principles to individual cases. I also realized that our developers did not need a specification—they needed training. I had no budget for a usability trainer or a large training facility, and no ability to disrupt the busy schedules of the software developers. However, I did have one month and several piles of usability documentation that I downloaded from the Web.
The experiment
I went back to management with a proposal: I would provide daily lessons via e-mail to the developers. Each lesson would take 15 minutes, and the entire usability course would last 20 days (one working month). Each daily lesson would contain a brief introduction and one or two links to existing topics on the Web. Occasionally there would be additional links to optional reference material. The developers could read the lesson anytime during the day at their convenience, and they would not have to disrupt their schedules to attend class.
A trial run was launched. In early 2000 I sent the first mailing to a test group of software developers, managers, and executives. The response was very favorable and I was given the “go-ahead” to provide the entire course to all the project developers. Several months later I mailed the same lessons again to software developers who were working on other projects. In 2001 I sent a third mailing to newly hired software developers. Finally, in 2002 I was asked to update the lessons and send them to our Vancouver office for distribution there.
Some limitations
Using e-mail lessons to deliver training has its advantages, but it also has limitations. In their most simple form the lessons have no exercises to reinforce training, and no testing to prove competency. Because the lessons use material from the Web, you must update expired links when necessary. In addition, management must give explicit support for the training in order to maximize participation by recipients.
Results
The e-mail lessons were valuable in that they introduced usability concepts to the company, but we are no longer using the lessons for training. We now need to formally integrate usability concepts into our development processes. This integration includes coordinating product requirements with customers’ needs, requesting customer assistance to test our interfaces, developing a company design guide, and providing targeted training to our employees. Because of the e-mail lessons, usability principles are now accepted without question in the company. We currently have an outside agency under contract to help us institutionalize usability practices.
The next step
One variation of the e-mail lessons that may prove useful for our future requirements would be to develop in-house content for the e-mail links. Usability training could then be highly customized for our employees, and there would be no reliance on Web links that might expire unexpectedly. And by using a free open-source CMS such as Moodle (Modular Object-Oriented Dynamic Learning Environment at http://moodle.org) we can include user authentication, lesson branching, quizzes, and automatic grading fairly easily. From there, it is a small step to developing e-mail-triggered introductory product training for our customer training packages.
This article originally appeared in the May, 2005 issue of Borderline, newsletter of the Southern Arizona Chapter. To see some of the lessons visit http://www.stc-saz.org, the Resources page, March 2003 section.