Save time and increase usability

by Judy Petersen

An early inspection of the interface can save money and headaches at the end of a project.

Often, different people prepare different sections of a product's functional specifications. And different developers develop different modules of the system. The result? Inaccurate, inconsistent usage and inconsistent spelling, capitalization, and punctuation of the wording on the product's interface.

So to save time and increase usability, ask a technical editor to study the specifications before development begins. When information is corrected early, fewer errors occur at the end of a project when time and resources are stretched to the limit.

From the specs, a technical editor locates problems and creates a style sheet for the development project. (A style sheet is a simple list of terms. This list shows exactly how terms must appear and if necessary, describes how terms are used.)

All developers can use the style sheet when creating the interface and documenting their development work. Later on, technical writers can use the same style sheet to ensure that the user documentation is consistent. The style sheet can also be transformed into a glossary.

After a prototype is created, ask the editor to edit the interface and the most current system documentation before the code is frozen. That way, when user documentation is developed, writers need not spend a lot of time figuring out how to handle terminology errors and inconsistencies when they document user tasks or reference information.

Several years ago, a software development company asked me to edit and test all online information for a large financial application. I found many inaccuracies and inconsistencies. For example, the word breakup was written six different ways: breakup, break up, break-up, BREAKUP, Break up, and Break Up. The correct term is breakdown.

When I asked the developers why they used breakup, they told me that it sounded more positive than breakdown. The problem? Users needed a function to create breakdowns. And an even bigger problem was that it was too late to change the help, messages, and documentation. So the application went public with this and many other errors and inconsistencies.

 

Reprinted with permission from Saga, a newsletter of the Stockholm chapter of the Society for Technical Communication. For more information, contact: Judy Petersen.