Readability/Usability/Quality 4-97 (December 1997) by Julie Fisher France

to the development of an information system?

In recent months, as part of my doctoral research, I have been interviewing technical communicators, users and developers of information systems to try and find out if in fact the work of a technical communicator is of value to those developing and using information systems. The interviews demonstrated clearly that technical communicators do add value. This was further confirmed in Paris where I discussed my work with technical communicators at the Comtec ’97 conference. The following discussion encapsulates some of the comments from participants at Comtec ’97 and the interviews I conducted.

 

Designing for delivery of information via the web

In the new era of electronically distributed information, the skills of the technical communicator will be in far greater demand than ever before. Conference participants stressed the importance of web page design for users. When a web site is carefully designed users will access it more frequently and will extract information from it more successfully.

Technical communicators can, using their skills, help in the design of more effective web sites. Two developers of information systems delivered via web sites were interviewed both said the contribution of the technical communicator improved the quality and usability of the site. For example with one system, the inclusion of a small moving picture of a butterfly flapping its wings, was used to draw attention to the help button. Usability tests had demonstrated that users had been unable to find the button, it had been difficult to see amongst other graphics on the screen. A re design, by the technical communicator, of the screen and the inclusion of the moving picture resulted in more users finding and using the help button.

To measure the success or value a technical communicator adds to a web site one conference participant suggested encouraging visitors to the web site to comment on the site using email. On the second web system the developers decided they wanted feedback from users. The text for a button to seek users’ comments was designed by a technical communicator. Originally the developers wanted the button to be labelled ‘Exit’, the technical communicator did not think this would work and suggested a number of alternatives, the developers still wanted ‘Exit’. To settle the issue a usability test was conducted and the users’ preference was for ‘Before you go’, the suggestion of the technical communicator.

From conference participants and those interviewed for my research, the message was clear, technical communicators should be involved in the design of web pages and web sites. Poorly designed web pages do not encourage users to return to that site and for businesses trying to do business via the web, this is important.

 

Information retrieval

Much discussion at the conference focussed on the more effective delivery of information. How, using the skills of a technical communicator information retrieval is improved, the quantity of material needed is reduced and communication within the organisation is made more effective. In one company the user documentation prepared by the technical communicator helped sell the new system to the users, the users instead of approaching the change with trepidation were looking forward to it. In the eyes of the developer the quality of the documentation was the reason for this. Two other developers said because the user documentation, written by a technical communicator, was of a high quality it helped sell the product.

One conference participant described how she had reduced a 120 page manual on how to use an email system to a cleverly designed finder wheel. Two circles joined together that when turned answered most of the users’ questions. The marketing people loved it, they used it as an advertising tool printing more information about the product and the company on the back of the wheel and posting it to potential clients. The technical communicator in this case, was able to evaluate how information was to be used and so designed an appropriate solution, one that focused on users’ needs rather than developers’.

The issue of helping the user identify where information is found was an issue raised by a conference participant, for example ensuring icons are meaningful. Another participant added that technical communicators can ensure that information presented to users via the screen such as icons, buttons, tool bars etc, is obvious to the user so the user does not have to remember what to do next time that command or function is needed. This saves the user time and reduces frustration. One technical communicator interviewed described a problem she had when using a system she was documenting. She clicked on an icon that was a question mark assuming it was online help, it was not, it contained information about the product. The technical communicator drew this to the attention of the developers suggesting users would be confused. Unfortunately the developers were happy with the way it was.

A number of conference participants stressed the importance of having a technical communicator write information that is later translated. The quality of the translation is better because the text is clearer and more concise and therefore easier to translate.

 

The technical communicator as system tester

Technical communicators begin the usability process was the view of one participant, because they are evaluating and testing the system. Technical communicators are using the system the way the users will. Many of the developers and technical communicators interviewed identified the role of ‘unofficial bug finder’ as an important role. They stressed how this role added value in the development of an information system. There were many examples of the types of bugs uncovered by technical communicators such as running a function that crashed the system, finding the output of a process was incorrect because it gave the user the wrong answer, the new system clashed with other software that was running and subsequently crashed, clicking on buttons that did nothing and finding a screen saver that when it came on the user was unable to re-enter their password so could not continue working.

If the technical communicator finds bugs at an early stage then they can be fixed, if not problems have to be explained away in the documentation. In finding the problems early the technical communicator saves the company money and time and generates a more positive response to the product from the users as well as making the product more useable.

 

Early involvement

When the technical communicator is involved early in the development process there is obviously more opportunity for them to contribute to the design and comment on issues relating to usability. In addition however, two participants at the conference mentioned the importance of having a technical communicator involved in writing the system specifications before the system is designed. One participant described how she was asked to document or describe the data base scheme in a way that made it clear. At first she was reluctant, expressing the view ‘what do I know about this?’. Once involved she realised how important the process was because she was able to identify problems the users were likely to have with the design and point these out to the developers. Another person said that through their early involvement they were able to provide the users from the outset, with an overall perspective of the system. One of the developers interviewed did not find out until the system was being documented that the users’ perspective of what they thought they were getting was quite different from the development team’s perspective. This did not emerge until the technical communicator was talking with the users about the user documentation and found himself explaining to the users what the system was to do. The developer commented that next time he would bring the technical communicator in earlier because he saw the value they could add in helping users understand what they were getting.

 

How can value be measured?

This is a critical issue for technical communicators. How do we quantify the value that is added by a technical communicator’s involvement early in the development of an information system? An obvious measurement tool is the reduced number of calls to the help desk (this was mentioned by two of the developers I interviewed), but it is far from the whole story.

Measures suggested by Comtec ’97 participants included

• increased number of hits on a web site
• length of time spent on a web page
• users willingness or reluctance to pay for a web site
• reduction in the quantity of material or documentation required
• increased product sales
• reduced translation time
• increased repeat business (i.e. the developer’s willingness to use a technical communicator again)

There are many other areas where technical communicators add value but these were the key ideas expressed by those at the conference. If you have examples of where you believe you add value we would love to hear from you, please write in so we can share them. I would like to thank those people who participated in Comtec ’97 and came forward with their ideas it was a lively and interesting discussion.  

"transline Deutschland - Übersetzungsdienst für technische Übersetzung"