Tuesday, October 08, 2002
Japan Inc. goes soft…
The Japanese electronics industry is changing towards a software-based product line, away from the traditional PCB-and-solder foundation that sustained it through the bubble years. While the user of typical products only a few years ago worked with push-buttons and toggle switches, today’s products are more than likely to incorporate a microprocessor and a display screen to “help” the user make the most of the new gadget.
As a writer of manuals for a variety of such electronic devices, I find that this affects the way that I work with my customers and their new products in a number of ways, and I am sure that my experiences are not unique. For those of you in the same line of work, it would be interesting to read your feedback on the points I make here. For those of you baffled by the instruction manual on how to use your new widget, which at first sight appears to be written in English, but on close inspection corresponds to no known language, this may give you some insight into the processes involved in writing a manual.
Development cycle
Firstly, the attitude of the engineers towards the product development cycle has changed. Whereas in the pre-software age (the Hard Ages), an engineering change order involving a new function added to the product could take several weeks to implement, with changes to the circuit board layout, the sink-screened front panel, etc., today’s engineers in the Soft Age can (and do) make changes to products under development, dropping and adding software features in a bewildering (to the technical writer at least) fashion. Furthermore, older engineers often cannot make the transition to a software mindset, and the younger engineers who produce the software often lack the production discipline that has been acquired over a period of many years by their hardware counterparts. This means that there may be a lack of proper product specification, versioning, and revision control during the development process. In fact, a unit may be sent to the factory (often outside Japan) for mass production, and the units coming off the line may sit there for a few weeks, waiting for the final ROM containing the production code to arrive from the development center.
All of these factors make it very difficult for a technical writer to produce a manual simultaneously with the product release, since the product itself is often in a state of almost organic flux, with changes occurring up to the last minute. Unfortunately, the process of producing film and plates, and printing and binding the manuals cannot be speeded up correspondingly, with the result that the documentation may not describe the final product (few manufacturers seem to consider that producing accurate timely documentation which might actually help the user to understand and use the product is a valid reason for delaying the release).
Product quality
Also, it has to be said that Japanese embedded software is typically not up to the standards of that produced in other countries; there are many reasons why this should be so, which I don’t propose to discuss here. A number of Japanese companies have bitten the bullet, and use outsourced Indian (or even American) software teams, providing functional specifications and hardware interface details to these subcontractors. However, the reasoning behind the menus, the screen navigation systems, etc. can often elude Western minds, and this can force the manual writer to produce logically consistent explanations of illogical processes (an interesting and brain-warping process). Funnily enough, when questioned, the engineers often have a consistent explanation of why the user has to jump through hoops to operate a product, but this explanation is usually geared towards the engineers’ problems, not those of the users.
Even so, there have been times when my suggestions in the early design stages have added value to the product, in that the final user interface design is simplified and easier to understand for the user. Hint—a manual writer, used to presenting complex information in a simple way, is often one of the best sources of ideas for interface design.
Software testing and the idea of software quality assurance is not nearly as well-established in Japan as elsewhere. Secrecy is a part of most Japanese companies’ corporate culture, and the idea of sending prototypes outside the organization for beta testing is not a common one (and programmers worldwide are notorious for being the most inefficient testers of their own work). The result with software-based products can sometimes be a release of a product which would still be regarded as being in the larval stage in the West (if I am lucky enough to receive a prototype of a product, I can often act as a software tester, though).
What you see…
Of course, this is an entirely different issue from that faced by the screen and interface designers, who often have to pack a lot of meaning into 16 characters or fewer. I find myself often being asked to help with the error messages and instructions displayed to the user—a task more akin to writing haiku than it is to traditional manual writing. When the Japanese engineers are left to their own devices, problems may occur (I remember once when the word COUNT had to be abbreviated to four characters in a display—no prizes for guessing which letter was omitted by the Japanese engineers!). But after all, these people are picked for their engineering, not their linguistic skills—it’s a little unfair to criticize them for this aspect of their work. However, error message writing is one more service that an experienced industrial writer can provide for his or her clients.
Restructuring the manuals
Most importantly for the technical writer, there needs to be a shift away from the “this button does this” approach to manual-writing so common with many Japanese manufacturers. Typically, a lovingly-designed drawing of the product is shown, with numbered arrows pointing to each and every hardware feature (the arrows are often numbered in an order which has little logic as far as the user is concerned but makes sense to the engineers—maybe this is a legacy of Japan’s crazy street address system). Over the next few pages, it is typically explained that “this button does this”, “this button does that”. With a simple analog device, such as an amplifier, or even a more simple-minded device, such as a VCR, such an approach can work reasonably well.
With a software-based product (such as a car navigation system, for example), of course such a simple-minded explanation is not possible. The same button will often produce many different results, depending on different states of the unit.
I have been trying (with some success) to eliminate the “numbered arrow” approach in favor of more general “roadmap” systems, where the front panel is still displayed to the user, but a box surrounds the “Audio Controls”, another surrounds the “Navigation Controls” and another surrounds the “Menu System Controls” (using our in-car entertainment/navigation system as an example) and cross-referencing these to the relevant portions of the manual (“How to use the menu system”, etc.).
Alas, although the products are becoming less intuitive, as they rely more and more on software that often makes little sense to the user, budgets are getting tighter, and the amount of money available to produce manuals becomes less. The result? More and more products are not understood by their purchasers, and either gather dust, or (in the USA) are returned for a refund.
Until all manufacturers realize that the documentation is a key part of the product, and allocate funds and space in the development cycle for its production alongside the software driving the product (though it must be admitted that some already do), the traditional Japanese mastery of the electronic gadgetry field seems as though it may come to an end.