There are significant usability problems with the original screen which is difficult to comprehend. Among the usability issues are the following:

1. In general, the screen is not designed to facilitate perceptual processing.
2. The heading is badly formatted. The page number appears in the middle of the line and has leading zeros (an artifact of field processing?). There appears to be a selectable item in the middle of the heading line, presumably to change the "as of date". Line 2 contains an incomprehensible number (screen id?)
3. Customer name is buried in the text and would be difficult for the service rep to read.
4. Extra space preceding colon in account number. A similar problem with the AND/OR on the next to last line.
5. List of items is difficult to read. This occurs because each item takes two lines. There are no headings. Labels "Unit:" and "Batch:" are redundant. And do not need to be repeated in each line. The activity code "ORDER ENTERED" takes a lot of space and could be condensed.
6. Select options at the bottom are confusing. Not clear how to use the AND/OR option in conjunction with the SELECT OPTION.
7. The function key legend at the bottom is sloppy and difficult to read.

Revision of the 3270 Screen

There is a myth that character-based screens are inherently unusable. This need not be the case. Following is a revised version of the original screen, redesigned for readability without changing the data.

The revised screen is built on the same 72 by 23 line matrix using the same font. It is much more readable.

1. The heading has been revised to make it a more readable. I did not remove the selectable item nor suppress the leading zeros in the page number, although this would be appropriate. I also left the peculiar "OPZ30700" id number since I was not certain what it was.
2. The name was converted to bold and centered so it would be more readable. The account number was positioned next to the name.

3. Each transaction was converted from a two line entry to a single line; this considerable increases readability. Removing labels which were repeated, shortening the activity code (e.g. ORDER instead of ORDER ENTERED) and combining the "Unit/Batch" entry into a single code retrieved enough horizontal space to place each transaction on a single line. The title of the item was limited causing truncation on the "AMA Medical Home Encyclopedia".
4. A heading line was introduced to label the columns. The loss of two lines is more than compensated for by the reduction of transactions to a single line.
5. A horizontal line separates the data entry area from the data area. The definition of the data entry codes and the PF keys is separated from the area entry area. There is still ambiguity as to how to use the multiple entry lines.

A GUI Version

The following GUI version of the same screen is intended to show the type of design opportunities which the GUI environment offers. Since this screen was not designed in conjunction with an analysis of the workflow, it should be viewed as conceptual rather than definitive.

The GUI design uses a scrolling listbox to display the transactions. Scrolling is not available on character-based terminals which must display lists too long to fit onto a screen in pages. The ability to create a scrolling list is a significant GUI design advantage.

A set of controls is associated with the listbox. A pair of radio buttons allow the user to select between a display of account activity and a contact history. There could be additional views. If the number of views were too large to fit comfortably along the bottom of the listbox, the final radio button could select a drop down box with additional views

Cognetics LUCID Methodology

In developing the re-engineering designs discussed below, Cognetics employed its Lucid Design Methodology. The Lucid Design Methodology was developed by to provide designers of software with a structure for integrating usability engineering into the software development process. Lucid, which is an acronym for Logical User-Centered Interaction Design, was designed to ensure a quality software product. Following the QUE Design Methodology will not compensate for a lack of creative talent on the part of the designers but it does provide a framework within which creative designers can function efficiently and effectively. By following the LUCID Design Methodology systematically, designers will be able to accomplish important tasks such as the following:

• Develop a clear product concept that will assist in communicating project’s goals and provide a means for ensuring the conceptual integrity of the software product.

• Identify the business objectives that motivate the product development effort.

• Acquire an understanding of the structure of the user population and the needs of each segment.

• Construct a complete needs and functionality analysis from the user’s perspective.

• Develop a navigational structure which implements all required functionality in as simple a manner as possible.

• Create screen control and display objects to efficiently implement the navigational structure.

• Develop a prototype embodying the key screens and navigation

• Refine and extend the prototype through usability testing

• Develop a complete set of programming specifications for the "front-end" of the system

The six stages that comprise the LUCID Design Methodology are generally intended to be performed in sequence. However, each individual element is subject to constant refinement. As the project progresses, the usability engineering team continues to refine the design, increasing its precision and level of quality. Specific deliverables are associated with each stage of the methodology and each deliverable is refined as a result of reviews, access to additional information and usability testing.

A key element of the LUCID Design Methodology is based on a process of rapid prototyping, A highly preliminary prototype (perhaps on paper) is created during the first stage of the process. This prototype is continually refined throughout the design process. The result of this is that users can visualize the product as it becomes increasingly well-defined. This is important because many users cannot visualize a software product from specifications and flowcharts. If they cannot visualize the product the quality of their input will be limited.

The table below presents an overview of the LUCID stages:

Case Study: The Maryland department of Juvenile Justice

Maryland’s Department of Juvenile Justice (DJJ) processes about 50,000 cases each year. Their current legacy system supports all aspects of juvenile case tracking for Maryland's Department of Juvenile Justice. Cognetics Corporation worked with the Human-Computer Interaction Laboratory (HCIL) of the University of Maryland to analyze the needs of the Department and develop a re-engineered design.

The decision to undertake replacement of the legacy system was based on an analysis of problems relating to the existing system. In particular, the following major problems with the existing software were identified:

• The existing system operates on obsolete IBM 3270 character-based terminals. These terminals are incapable of utilizing a Graphical User Interface.
• There are an inadequate number of terminals available to service staff needs.
• Staff finds the current software confusing and difficult to use. It is regarded as an imposition rather than as a work support tool.
• The current software does not adequately support the current needs of the service and cannot easily be reprogrammed.
• The current software has inadequate reporting capabilities.
• The current software is based on obsolete data base technology.
• The current software lacks certain key functionality needed to interface with external systems.
• The current software does not support the most efficient models (best practice) of processing information important to the Department’s business.

The new system was envisioned as a replacement for the current legacy system. As such, it must accommodate the functionality of the current system and also add increased functionality and reliability and better integration with other systems. The new system was designed to function as an integrated performance support system. As such it was intended to assist staff in performing their day to day activities.

While the legacy system used dedicated communications lines, the re-engineered system incorporates Local Area Networks and workstations in individual DJJ offices, standalone desktop computers with WAN access and dial-in connections. These systems are tied together by public data packet service and/or leased lines, using installed cabling to the extent possible. Connection of the computers of other agencies is highly desirable but not yet worked out due to coordination problems.

The illustration below shows the configuration of the new system.

While the legacy system operated on dedicated 3270 terminals, the new system was designed for desktop computers running Microsoft Windows (95 or NT) operating system. Each PC is equipped with a 17 inch monitor and supports a resolution of 1024 by 768 pixels in 256 colors. Each PC is either directly connected printer or be connected by network to one or more nearby (same building, same floor at least) printers.

One of the problems with the legacy system was that users did not have ready access to a terminal. Therefore access to the computer was never casual or well-integrated with work tasks. A requirement for the new systems was that each user have access to a conveniently located PC. In addition to the system, the user would also have access to email and a word processor, as well as other standard office software.

The following chart is a simplified version of the Juvenile Justice System interaction with a juvenile case. The initiation is a complaint of some sort--in most cases a police complaint. That is followed by the DJJ intake process which culminates in a decision between four options: closed at intake, disapproved, informal and formal. Informal or closed cases may include time in DJJ or community programs. Formal cases are turned over to the State’s Attorney and are adjudicated in juvenile court. During this process the youth may remain at home or be housed in one of several ways, depending on the circumstances. If the case makes it through the court process to disposition, the youth spends some time in a DJJ program, after which he/she may also be in aftercare. The juvenile court makes the decision for termination.

The re-engineered design took advantage of a complete series of process maps developed by DJJ to identify all points at which a computer could intervene in the process.

One design element of the re-engineered system was that each type of user has a unique view. Thus a field worker, a residential worker or a medical worker will each get a different view of the system based on their job responsibilities. The screen below shows the field worker desktop:

This screen has a listing of all assigned cases. The worker can get to the details of any case by simply clicking on the youths name. This brings up the Youth record screen.

An interesting feature of the youth record, not possible on the legacy system is the use of a photograph to show the youth and personalize the record for the case worker and the lifeline display (developed by the University of Maryland) which illustrates the youth’s history at a glance.

As an alternative to almost 200 legacy screens, the re-engineered system uses lists of events and dialog boxes to maintain the entire youth’s history on a single screen.

Case Study: A Banking Workstation

In November 1995, Cognetics was asked to participate in a re-engineering project for the retail division of one of the nation’s largest banks. The client, the retail bank of a large national bank, felt it was imperative to re-engineer their software which was twenty years old and based on outmoded banking models. The software was mainframe-based with information delivered on IBM 3270 character-based terminals.

Much of the software was programmed in CICS and delivered on "dumb" terminals. Both because of limitations in the technology and inconsistencies in the , there were significant problems with the usability of the system. On average it took five days to train a new user.

The software consisted of multiple host systems. It was therefore necessary for an employee to have several sessions operating at a single time. Switching among active sessions was accomplished by "hot" function keys.

Over the past 10 years, the emphasis in banking has changed from an account orientation to a relationship orientation. The old-style of banking was to treat each account as an independent unit. Mainframe systems were organized by account number. The model of the retail (consumer) bank was a front-office which accepted transactions and passed them to the back-office (or "factory") for processing.

However, more recently, banks have begun working with a segmented relationship model. Customers are divided into market segments according to their characteristics. Typical segments are mass-market, preferred banking (typically customers with incomes of $75,000-$125,000), and private banking (customers with a net worth in excess of $1 million. Other segments may be defined, depending upon the particular bank’s marketing strategy.

The client bank felt that by creating customer segments, it would be better able to tailor services to the customers’ needs. The bank’s vision of the future was that it would become a virtual bank with a relationship banking service model. As banks have taken on additional products such as mutual funds and insurance to their product mix, they have moved to relationship banking models in which the bank changes its transaction-oriented operation to a model in which the bank acts more like a financial advisor, attempting to meet all the customer’s financial needs.

We found that the way that data is organized on the host and accessed through the legacy systems had a profound effect on our ability to design the new workstation. The relationship banking required that we display the customer’s complete financial picture and shift assets around as circumstances and opportunities dictate. However in the past banks tended to organize data by account and the legacy systems we were dealing with reflected that organization. As a result there was no single source to locate all the financial information about a particular customer whose financial information was spread across many host computers and different software systems.

This led to many problems. For example if a customer calls to change her address, in the relationship model it should be a simple matter to bring up the consolidated customer record and change the address. However, the disparate legacy systems required an address transaction for every single account submitted to each individual host. This either imposes enormous frustration on the customer or a massive clerical job on the bank.

We found other places where the way the data was aggregated was clearly not acceptable for a relationship model. Because of poor integration between systems, transferring funds between two accounts could require up to two hours of manual activity as data was printed out in the back office and manually entered into another system.

Although we would have liked to reprogram the entire system, the bank determined that it was not feasible to reprogram the host systems within the time and budget constraints, and opted for a middleware solution.

A server containing middleware code was to be interposed between the host mainframes and the terminals. The function of the middleware was to manage a new set of messages which would deliver the data in the desired formats and aggregations.

Strategic and Tactical Designs

Although the middleware solution was intended to reduce the magnitude of the re-programming required, there was still a considerable amount of coding required before it could be fully implemented.

Because management was insistent that the new workstation be fielded within a short time, the bank decided to implement an interim solution based on screen-scraping technology. This restricted our initial designs due to the performance considerations discussed earlier.

Recognizing these issues, Cognetics decided to develop two designs in parallel. A strategic design was created for implementation when the middleware programming was completed. An interim tactical design was created which could be used in a screen-scraping mode with a minimum of performance problems.

The creation of two designs posed a problem in itself. Users were introduced to the new workstations operating in screen scrape mode with the tactical design. When programming progress made the strategic design available, users should not have to learn a new design.

Cognetics therefore developed the tactical design to be a subset of the strategic design. Fields which could not be filled-in during early releases of the software were shown but were "grayed out". At times, it was even necessary to show 3270 screen in the early releases. In these cases we embedded the old screens within the new design and altered their look and feel to match the new design.

An Overview of the Design

The first stage of Cognetics’ LUCID Methodology is the development of the product concept. To begin the process Cognetics hosted an off-site retreat for both the business and technical staff.

The goal of these sessions was to:

• develop a clear and agreed-upon product concept
• identify all relevant user groups and their special needs
• identify all technical, legal or operational considerations which might affect the design
• agree-upon responsibilities, procedures, deliverables and communications among the various groups
• develop one or two very preliminary screen concepts to allow users to react and programmers to asses the complexity of implementation.

A large amount of data came out of these sessions. Among the key findings were the fact that different user groups had very different priorities. In particular, the customer service personnel who staffed the telephone centers were evaluated on the number of calls they could process and wanted critical data on the first screen for speed. Account managers in the upper income segments, by contrast had many fewer client contact per day but these contacts were far more complex. They needed screens that could account for such elements multiple residences, many accounts, and off-shore assets.

Cognetics provided both usability engineers and graphic designers at the sessions. Preliminary screens were developed and discussed. The basic look and feel which emerged from these sessions was retained throughout the project. It used a desktop metaphor with buttons down the left side. Sophisticated colors were both pleasing to the staff and restful during long sessions:

Client View

The client view screen is the basic screen which contains the information for a client or prospect. The client view screen can be accessed in several ways. When a telephone call is received, automatic equipment checks the incoming call number against a database of clients. If there is a match, the client view is automatically popped up.

Alternatively, the account executive can locate a client screen through a search procedure. After entering the information into a search dialog box:

The search request is passed to the host. There are several million clients on the host system so there may be more than one possible name returned. The system proves a search results screen which the account executive can inspect to determine which is the correct client.

These searches are necessary because the bank has many business units and policy requires that the account executive be aware if an individual calling is a customer of any business unit of the bank.

There are additional ways to locate a client. The system has a workflow management section in which account executives can note clients who should be called. In addition, the system automatically creates entries for clients who are in the middle of a processing cycle (for example a mortgage application) or whose data indicates a possible sales opportunity. All these "tickler" entries link directly to the client record and allow the record to be retrieved in a single step.

Conclusions

Based on the experience described in this paper, we have realized that there are special concerns which must be taken into account when legacy systems are re-engineered. Rigidity in design architecture based on the message communications and database structures of the host are a serious consideration. We also found that GUI interfaces can slow some users down.

In general, emulation and screen scraping technology is less than satisfactory. Middleware solutions can provide flexibility at a significant hardware and software cost.

The opportunity of re-engineering is to replace systems with new designs which support the workflow process. Such systems need to be designed to uncompromising standards of usability.