An important aspect of any information system analysis project is to gather user input. Traditionally, user input has been gained through either individual or group meetings, interviews and questionnaires. Once this information has been gathered, usually in the form of written system requirements, system design specialists begin the task of coding the information system. Over the years, it has become apparent that systems developed using the traditional method of obtaining user input hadve usually failed.

Below are three examples from industry (RouteBuilder, Apple Computer, and Hewlett-Packard) that illustrate how iterative user input received during the analysis phase of the systems development life cycle increases system success. Of course, this "success" is measured by many factors. Not only does the system have to meet the stated requirements and function as intended, success also depends how well the system meets the needs of the users.

What many system developers have come to understand is that meeting the needs of the user is hard to quantify and cannot be simply stated in formal system requirement documentation by including the term "user friendly". So how does a System Analyst determine if a system meets user needs?

One method is prototyping. As part of the system analysis phase, a model of the system is developed and presented to users for feedback. The prototype is an example of the system analysts' interpretation of what the system is and how it is supposed to function. Prototyping gives the user the opportunity to make comments and suggestions that will clarify their needs to the systems analyst. Thus, this iterative process allows the analyst to more clearly define requirements and components of the user interface.

The Effects of Practical Business Constraints on User Interface Design

This case outlines the development of RouteBuilder 3.0 and the iterative prototyping process used by developers. Using the experience gained from the development of RouteBuilder versions 1.0 and 2.0, the development team broke down the individual components of the new system into separate prototypes that were then tested for usability. To keep within time and budget constraints, prototyping tools included both paper and third party applications such as Visual C++, Visual Basic, Microsoft Foundation Classes, and even applications not normally associated with prototyping like Microsoft Excel and Microsoft Word.

One of the "lessons learned" from this project was that software prototypes developed during the analysis and design phases do not have to be considered as part of the final product. Creating prototypes for individual features can be completed quickly to solicit user feedback and then the prototype can be considered disposable. This allows rapid prototypes to be built instead of code that takes time to develop. Because of the cost and time involved in creating coded prototypes, sometimes management feels compelled to use it, even if the user feedback is less than favorable. By employing individual feature prototypes to gain user feedback, system coding can be held off until developers have a clearer understanding of user needs.

A case study in interface design: The CHI'89 Information Kiosh(sic)

This case outlines how rapid prototyping was used by Apple Computer to design an information kiosk for a conference attended by user interface designers and researchers. This was a six month project that used an iterative process of sketches, story telling and prototyping as a means of analysis and design instead of written descriptions of the system and user interface.

By soliciting user feedback at each stage, the developers were able to quickly determine if potential users were able to understand interface objects as the designers had intended. Since drawings were used in the initial stages to get user comments, a running prototype could be employed later in the process to test usability by potential users. This iterative process of soliciting user feedback allowed the developers to easily change the system to meet user needs and was viewed as major reason the project was a success.

Replacing A Networking Interface "FROM HELL"

This paper describes the process used by Hewlett-Packard in redesigning their network troubleshooting program called NetTL. The first version of the program used a command line interface that required users to learn a language described as archaic and cryptic. Many users found it so difficult that some users "refused" to use it all and others used only a portion of the system capabilities. The development team analyzed the users to determine key system components and developed a three step iterative process of design/redesign, prototyping and evaluation to successfully redesign the system.

A paper prototype was used for the first step. The second step utilized a computer model that could be navigated and where data could be manipulated. In the third step, the interface was redesigned and the prototype revised. During each step, end users participated in an evaluation of the system.

This process was a departure from the normal method Hewlett-Packard used for system analysis and design. Instead of design and code, evaluation and then redesign and recode, this method involved the user input in each prototype and moved the actual coding of the system until much later in the design process. This user oriented methodology was so successful that it persuaded management to implement user-centered design in the development of other projects.

The Analysis and Prototyping of Effective Graphical User Interfaces

Design Principles

What Is Prototyping?

References

URL: http://www.umsl.edu/~sauter/analysis/prototyping/intro.html
Project Team Members: C. Melissa Mcclendon, Larry Regot, Gerri Akers