Previous Table of Contents Next


The usability engineer will plan and lead the design of the user interface and ensure that it fulfills predefined usability requirements. This is accomplished through usability testing and evaluation of user interface prototypes. The usability engineer has formal training and/or experience in usability engineering or human factors. He or she will work together with the system designer and the technical communicator in the usability team.

Traditionally the user interface has been defined as the graphical layout of the program, as it is seen on the computer screen. The Delta Method expands this concept of user interface to have a wider meaning. According to the Delta Method a user interface consists of three equally important parts:

  The services offered to the user by the system (i.e., the functions directly supporting user tasks).
  The actual graphical presentation of the services on the screen (traditionally referred to as the user interface).
  The enabling information (e.g., the user documentation) needed by the user in order to be able to use the system efficiently.

All three aspects of the user interface are taken into consideration when the requirements on the system are defined. The process of defining the system functionality is influenced by how it is to be presented to the users and the knowledge and information that is needed to use the functions. Since the enabling information is a part of the user interface, it is important that the technical communicators and the system designers cooperate during the design process. This ensures that the different parts of the user interface are designed in a consistent way and that the services offer a comprehensive view of the system. In other words, working according to the Delta method means that system designers and technical communicators work side-by-side during analysis and design, with the aim of preserving the interests of the users.

3. THE CASE STUDY: TSS 2000

The case study describes a project to develop the next generation of a Telecom Simulation System, TSS 2000, a tool used during the installation and testing of switched and cellular communication equipment from Ericsson. TSS 2000 will typically be used to test the capacity of telephone exchanges and base stations for cellular phones. A sample test case would be “Shinkansen”. Imagine the Japanese express train Shinkansen running at a speed of over 200 km/h, transporting hundreds of commuters between Osaka and Tokyo. All of them decide to call home at the same time to find out what’s for dinner. TSS 2000 offers the possibility to generate a realistic traffic load and simulate how the calls are handed over between base stations along the track.

The goal of the TSS 2000 was to integrate the capabilities of two existing test tools and also offer additional services. The focus of the project was to merge the tools and rework them as necessary. It was believed that poor usability was a dominant factor in many of the user complaints about the old products. Some of the more technical problems would be addressed in the new system, but there was a need to address the usability problems in a more systematic way. During the spring of 1996 a group of system developers and technical communicators initiated a study to improve the usability of the new tool.

The purpose of the usability study was to produce

  An on-line, evolutionary prototype.
  A test specification for the user interface.
  A design specification that contains measurable requirements for both the user interface and the user documentation.
  Guidelines and recommendations for a conversion from Open Look to CDE/Motif.

Although the fact that usability had been identified as an important aspect of the new product, substantial lobbying and internal marketing was still required to get the usability study going. The effort to design and implement the functionality of the system was massive and, compared to the task of “getting the system up and running”, usability was considered a minor problem. Once the study was approved we faced some restrictions:

Only a new UI — The study was limited to “improving the user interface of the tool.” At the start of the project there was very little understanding for the need of an “open-ended” usability study.
Just port it — The old test tools ran on PC and UNIX platforms using a character-based user interface and the Open Look look and feel. Ericsson is in the process of migrating all development and test tools to Motif/CDE. The need for moving TSS 2000 to Motif/CDE was used as an argument taking the opportunity to make a complete redesign of the user interface.
Ready by yesterday — The time schedule for the usability study was very tight. Everything that was not considered to be critical to the study was left for later, and every activity that we performed had to be trimmed to fit the deadlines. This has surely affected the quality of the study, but we simply had to produce the best result possible with the given limitations.

This case study is far from the schoolbook example of usability engineering; it is more of “Usability — shooting from the hip”. The initial time plan for the usability study, roughly 3 months, was very short. In this time we had to perform all the necessary usability activities, and there was little background information that could be reused to help us shorten the time for the study. This meant that we had to cut every corner and constantly publish reassuring results in order to secure more time and resources.

Due to the limited resources, design decisions sometimes had to be based on results that were a bit incomplete or unfinished, but in those cases we had to trust our intuitions. A method for usability engineering has to survive in the real world, adapting to the changing characteristics of the projects. To us usability is an engineering in practice; we will never design the ultimate user interface, but we always strive to produce the best possible result with the given resources. Many times the industrial usability engineer has neither time nor interest to study exactly how unusable a product is. The mere fact that the users have problems is enough for considering a redesign.


Previous Table of Contents Next