Looking for something?
By Richard T. Evans
When discussing ways to improve productivity with the personal computer, the discussion usually focuses on the mechanics of the computer, with memory and processing speed being favorite candidates. Indeed, I recently saw a discussion on an Internet newsgroup wherein someone maintained that the barrier to improved productivity was the lack of true 32-bit multitasking.
My experiences, however, suggest a different and far more mundane explanation. Let me illustrate with a sad tale regarding the preparation of mailing labels. I chose a Windows-based program, the name of which I am withholding to protect the guilty.
I began by entering a few addresses, then trying to print labels. First, I found that the most common label sizes were not included. The documentation offered no clue as to the prospects for adding labels to the list. I next tried to design a custom page for the proper label size but the result printed only one label per page then skipped to a whole new page. Again, the documentation was no help. I next called the technical support line and got someone who seemed to know less about it than I did. To add insult to injury, the company charges $3.00 per minute for tech support so an eight minute call cost me $24 and I had no answer.
I next resurrected an old DOS program. It didn't have all of the features I wanted but it printed labels effortlessly. I spent an hour or two typing in about a hundred addresses and printed the labels.
With my immediate problem solved, I went back to experimenting with the Windows program and discovered how to design custom pages. Rather than retyping everything, I used the export/import feature, exporting from the DOS program and importing to the Windows program. The import failed with a message about missing column names. Again, the documentation told me nothing and again I called tech
support. After only six minutes ($18) this time I learned that the import program didn't like the extension of the file I was importing. Column names had nothing to do with it. I changed the extension, completed the import, and finally had the database I had set out to create. The whole experience lasted over a week, took over eight hours of effort, and cost $42 in tech support calls. This is fairly representative of my experiences with software in general. Now, where is the opportunity for increasing productivity in this scenario? A faster processor? How many nanoseconds of processing time do you have to save to recoup eight hours of wasted effort?
I contend that the real boost to productivity lies in simply producing better documentation about how the product works. The questions I had were simple ones. They should have been in the book. Ignoring the obvious criticism that common labels should have been available as a default, instructions for creating those formats should have been clear. The directions for importing a file should have told me there was a specific file extension required. Failing that, the error message should have told me. The tech support people obviously had no better documentation than I did. My suggestion to the software industry would be to declare a one-year moratorium on developing new whiz-bang features, hire a task-force of writers and spend that year studying the interface and the tasks the user needs to perform, then develop clear, comprehensive documentation that would avoid the kinds of problems I've reported above.
When discussing ways to improve productivity with the personal computer, the discussion usually focuses on the mechanics of the computer, with memory and processing speed being favorite candidates. Indeed, I recently saw a discussion on an Internet newsgroup wherein someone maintained that the barrier to improved productivity was the lack of true 32-bit multitasking.
My experiences, however, suggest a different and far more mundane explanation. Let me illustrate with a sad tale regarding the preparation of mailing labels. I chose a Windows-based program, the name of which I am withholding to protect the guilty.
I began by entering a few addresses, then trying to print labels. First, I found that the most common label sizes were not included. The documentation offered no clue as to the prospects for adding labels to the list. I next tried to design a custom page for the proper label size but the result printed only one label per page then skipped to a whole new page. Again, the documentation was no help. I next called the technical support line and got someone who seemed to know less about it than I did. To add insult to injury, the company charges $3.00 per minute for tech support so an eight minute call cost me $24 and I had no answer.
I next resurrected an old DOS program. It didn't have all of the features I wanted but it printed labels effortlessly. I spent an hour or two typing in about a hundred addresses and printed the labels.
With my immediate problem solved, I went back to experimenting with the Windows program and discovered how to design custom pages. Rather than retyping everything, I used the export/import feature, exporting from the DOS program and importing to the Windows program. The import failed with a message about missing column names. Again, the documentation told me nothing and again I called tech
support. After only six minutes ($18) this time I learned that the import program didn't like the extension of the file I was importing. Column names had nothing to do with it. I changed the extension, completed the import, and finally had the database I had set out to create. The whole experience lasted over a week, took over eight hours of effort, and cost $42 in tech support calls. This is fairly representative of my experiences with software in general. Now, where is the opportunity for increasing productivity in this scenario? A faster processor? How many nanoseconds of processing time do you have to save to recoup eight hours of wasted effort?
I contend that the real boost to productivity lies in simply producing better documentation about how the product works. The questions I had were simple ones. They should have been in the book. Ignoring the obvious criticism that common labels should have been available as a default, instructions for creating those formats should have been clear. The directions for importing a file should have told me there was a specific file extension required. Failing that, the error message should have told me. The tech support people obviously had no better documentation than I did. My suggestion to the software industry would be to declare a one-year moratorium on developing new whiz-bang features, hire a task-force of writers and spend that year studying the interface and the tasks the user needs to perform, then develop clear, comprehensive documentation that would avoid the kinds of problems I've reported above.
Top of page
Staff and authors:
