Growing Simplicity: A Task-Based Approach to Containing Complexity

Keywords

Introduction

As more business processes are being reengineered, the number of automated procedures and on-line forms is steadily growing. Many such processes are information-intensive and require interaction with significant amounts of data. Developing information systems (IS) for these business domains presents a broad challenge to the user interface design team: how to present the requisite abundance of diverse data elements in a more easily manageable manner than the original paper/manual process.

Having many graphical user interface (GUI) toolkits, prototyping aids and application builders to choose from, the software engineering team can create a minimally functional interface prototype in a relatively short period of time. In the authors' IS environment, this is considered an important part of the specification phase of the system development process. The resulting prototype often tends to have a feature-based design, contain most of the user-specified requirements or features, and conform to general style guidelines of the particular interface toolkit employed. While it may meet the stated objectives and even take into account user perspectives, the prototype software may be critically deficient from a usability perspective if some fundamental design issues are not considered. We will discuss these issues, and the impact their consideration had on a particular business process reengineering project in the IS domain of Human Resources (HR).

THE PROJECT

The software system described in this paper, ESCtool, allows line managers throughout a large organization to process an employee status change (ESC) on-line. The ESC business process affects the employment record for job and compensation levels, management and departmental organizations, leaves of absence and work status, and various other elements regarding the employer-employee relationship. The software also provides on-line authorization and automatic database update capabilities, thus streamlining an otherwise time-consuming and error-prone manual process. The end-user community includes all managers in all levels of the organization, HR representatives, Finance representatives, Legal representatives and other special groups requiring the data such as Payroll, Commissions Accounting and Benefits Administration. The scope of the project included streamlining and automating a complex manual process, and making a very rich dataset (all facets of the employee HR record) available on-line for use by a diverse user community. Furthermore, the usage patterns, information requirements and computer experience of the user community vary widely.

Rapid Prototyping

As a part of the functional specification phase, short iterative cycles of rapid prototyping and user feedback were employed to communicate the project vision and better understand user needs. Feedback was incorporated into the subsequent prototype version using the application development tool[1] and redistributed to small user groups. The latter of these first ESCtool prototypes we refer to as the "Initial Prototype."

Initial Prototype

The Initial Prototype was an intentional departure from visual patterns used by the development group in the past, toward the more stimulating look-and-feel of newer software packages on the market. Pulldown menus were discarded in favor of icon buttons. In addition, rather than creating an electronic version of the paper ESC form, the interface design team sought to present only those data elements which would pertain to a user's particular transaction. With this model, a main palette of labelled icon buttons served as the launch point for opening subsequent windows, each containing distinct ESC data elements. After interacting with a series of popup windows to select an employee and specify various changes, a manager initiating an ESC would review the summary of intended changes on a separate window where they would press the submit button. With this interface model the design team sought HCI consultation.

HCI Consultation

The opportunity to run a complete usability study for the project presented itself, but was not taken because of the limited timeframe of the project schedule. Instead, the Usability Engineer employed an informal Cognitive Walkthrough[2] with the design team, polling for information about the tool, user population, and tasks while using the Initial Prototype for the first time. By leading the team through this process, the HCI specialist caused the designers to rethink some of their strategies and consider alternative approaches.

Challenged by the first session with the Usability Engineer, the ESCtool design team re-established their design criteria according to the notes taken from the consultation. The synthesis of those notes reveal four crucial insights:

• integrate main activities into main window
• make the flow obvious
• group similar activities together
• reuse information so that user enters it only once

The characteristics which stood out the most were the tool's non-linear flow, and the number of windows. In the sample worst-case scenario of a promotion/transfer transaction illustrated in the poster, the manager would need to interact with the main window six different times, and eleven separate windows in all!

After carefully considering these issues and creating a completely new prototype interface, the designers showed their work to the HCI consultant. While there were a few suggestions for refinement, the Usability Engineer confirmed the success of the new design approach and resulting interface.

Resulting Product

Having established the new interface model, the team converted the prototype to a new GUI toolkit[3], and incorporated many of the further HCI suggestions and other refinements into the tool. The result is a product comprised of two basic windows, where all of the main activities are integrated. Moreover, the flow is a much more intuitive top-to-bottom linear progression as illustrated in the poster.

Again considering the same sample promotion/transfer transaction, the required tasks begin at the top of the left, or main window and progress downwards, as the user specifies the type of change and the employee who is being affected (in the Initiate Mode). After specifying the nature of the change, the user then selects the Display Form button at the bottom of the main window. This action generates the Custom Form window, which appears to the right and contains the various components of the ESC change in a scrollable panel. After completing the information in a top-down fashion, the user can press a button to submit the transaction for approval. The same information is entered as in the Initial Prototype, but this time on just two windows.

CONCLUSIONS AND LESSONS LEARNED

With the Initial Prototype, the team had achieved its expressed intentions by directly mapping user requirements to corresponding interface features. But in the area of usability, the feature-based design method left the tool far short of its true potential. Although this is now clear with the benefit of hindsight, it was not the compelling reason for seeking HCI consultation at the time. Rather, the team sought suggestions for refinement, yet support for the basic model and perhaps an unofficial certification which might be claimed as an endorsement later.

Fortunately, two dynamics led to the team's new insights which significantly impacted the project outcome: 1) the design team was open to constructive criticism, and 2) the HCI consultation was sufficiently early in the project and the development organization had not yet invested too much in construction so that the team could respond to the Usability Engineer's suggestions. We believe these to be central to any project considering HCI consultation.

Because of the changed design approach, the team took a more systematic look at the tasks involved and the number of windows it required. Since the business domain and scope of this project required a tremendous amount of information be presented together, the challenge was non-trivial. In addition to the four insights gained from the HCI consultation, we learned four additional lessons from using the new design approach. We offer these for the reader's consideration:

• consider HCI consultation early in a project
• be open to change
• set tough containment goals for the number of windows being used, even if they seem unrealistic
• question the usefulness of every interface component

1. DevGUIDE by SunSoft, Inc. was used to create the Initial Prototype in XView OPEN LOOK.

2. Wharton, Cathleen; Rieman, John; Lewis, Clayton; and Polson, Peter (1994). The Cognitive Walkthrough Method: A Practitioner's Guide. In Nielsen, Jakob; and Mack, Robert L. (Eds.) Usability Inspection Methods. (John Wiley & Sons, Inc.), pp. 105-140.

3. The XView prototype was converted to Motif for unrelated reasons. However, Motif allowed us to more easily create a scrollable panel (a construct discouraged in XView), thereby fitting all components into a single window.