Rapid Prototyping: A Customization Strategy

Abstract:

The functionality of GIS now extends to the design and adaptation of the interface such that systems can be tailored according to an organization's style, tasks, computer literacy, and frequency of use. This paper proposes that a logical approach for interface customization is through a recursive consultation process that enables interface designs to be rapidly prototyped. We have dubbed this customization strategy: Rapid Prototyping. The rapid prototyping strategy has three stages: determine requirement specifications, design prototypes according to specifications, and evaluate a prototypes ability to accomplish these specifications. This customization strategy has been used to increase system usability and user performance levels at the Highland Council Planning Service (HCPS),Scotland. This paper offers specific techniques to accomplish the three stages of rapid prototyping. It is suggested that this strategy can be used to help tap the maximum potential of a GIS within any organization.

The customization of a Geographic Information System (GIS) to fit a particular context of use is becoming increasingly common, and an accepted characteristic of the technology. A growing number of organizations are realizing the importance of customization for ease of use, faster adoption of the technology and clarification of system functionality. However, customization alone does not guarantee improved usability. Findings of the Usable Spatial Information Systems (USIS), a project funded by the United Kingdom's Economic and Social Research Council to formally identify usability problems, found that in some instances: "there was no significant improvement in usability of user-customized systems over non-customized systems" (Medyckyj-Scott 1993, p.88). The results produced from the USIS report encouraged the authors of this paper to devise an effective, easy-to-follow, customization strategy to increase the likelihood of improved usability with customized systems. Our paper discusses a customization strategy called rapid prototyping as a method to create a more usable Graphical User Interface (GUI). Rapid prototyping is an iterative, three-stage process, of determining requirement specifications, designing the GUI to meet those requirements, and then evaluating the prototype's ability to satisfy those requirements (Figure 1). We offer techniques, and examples of how to successfully apply these techniques, for each of the rapid-prototyping stages. The customization of a GIS (ArcView 3.0) package for the Highland Council Planning Service (HCPS) is used to illustrate how these techniques can be, and were applied. Although these techniques are applied to a particular organization, we contend that the methods presented here are applicable to other organizations or individuals seeking to improve the efficiency of their GIS through customization.

For well over a decade, scholars have stressed the importance of a user-requirements analysis to help create more usable information systems. (Aronoff, 1989; Cox and Walker, 1993; Davies and Medyckyj-Scott, 1994; Eberts, 1994; Lindgaard, 1994; Newman and Lanning, 1995). However, there does appear to be significantly less information detailing a proven methodology of how to undertake such an analysis for the purpose of GUI customization. We present one here; it requires the creation of three tables, and a summary "User Report". Collectively, these tables and summary report provide a structure to gather the required information to successfully complete the first rapid-prototyping stage:

• Table of Specification goals to outline overall project aims.
• Table of User Requirements to develop an overall user-profile.
• Table of Task Requirements to understand user tasks, and how those tasks can be presented on the GUI in a user-friendly manner.
• Summary User Report to summarize the findings of the three tables.

A Table of Specification Goals should be created to help define the scope of the project from the outset. This table should clearly indicate the type of information that needs to be gathered before the process of customization can begin. Interviews, meetings, and questionnaires can help reveal these specification goals. The Specification Goals devised at the HCPS are used to illustrate this concept.

A User Requirements Table should be created to give an overall profile of a typical user. It is suggested that a broad user-base be used to develop an accurate organization-wide user-profile. Additionally, if the final customized system is to be implemented in different locations, than User Requirement tables should be created for each location. It is important to determine the range of user abilities as the system should accommodate both experienced and inexperienced users equally. The User Requirements Table devised for the HCPS is presented to illustrate this idea.

A Task Requirements Table should be created to help give an overall profile of typical user tasks. Task Requirement tables should clearly outline what GUI controls will be necessary to fulfill daily activities, and how these controls will be made user-friendly. Determining user tasks can be accomplished through meetings and interviews, but is most effectively accomplished by "walk throughs". A "walk through" consists of accompanying a user during a typical workday, and observing and inquiring about tasks undertaken. Users should be encouraged to vocally express what they are doing, and should be made aware that the "walk through" is being undertaken to help develop an understanding of their needs for the customized system. This promotes a relationship built on trust and mutual understanding between the user and the designer.

Walk throughs at the HCPS revealed that there were two primary tasks that HCPS users wanted to be able to accomplish with the customized system:

• Analyze an existing planning site.
• Digitizing a new planning site.

The Task Requirement Table for the first primary task illustrates how such a table can be constructed.

A Summary User Report should be created to summarize the findings of the three tables. This report should be presented to the users before any customization begins. This report aims to verify that designer intentions meet with user expectations. Figure 2 illustrates the HCPS Summary User Report.

In combination, these tables and summary user report were critical for determining the integration desired among the users, their tasks, and the system at the HCPS. These three variables have been described by Eason (1984) and Medyckyj-Scott (1990) as the prime determinants of GIS usability. Only after a thorough understanding of these specifications has been gained should designers consider beginning the second stage of the rapid-prototyping customization strategy.

It is common practice for most designers, be they engineers or architects, to create a prototype before implementing a final product. We offer specific techniques to ensure a steady rate of improved usability with prototype construction.

The progress from the first HCPS prototype to the final HCPS prototype can be seen in Figure 2 (the standard ArcView GUI is also included because it was used as a starting point to build the first prototype).

 First Prototype: Digital Representation of Sketched GUI done at HCPS

 Second Prototype

 Third Prototype

We suggest sketching the first prototype with an end-user. Considerations with the first prototype should involve deciding on what functionality can be removed from the standard GUI to reduce clutter and confusion, and how new functionality should be represented on the customized GUI (i.e. menus, buttons, tasks, pop-ups). Working closely with end-users enables them to contribute to the design of their own system. This promotes greater system acceptance as users are more likely to accept a system they helped design.

Reducing the functionality of the standard HCPS's ArcView GUI was done by explaining the functionality of the standard interface and then posing three key questions: "Could you see this function being useful?", "Would removing this function reduce your ability to fulfill planning tasks?" , and "How could this function be made more task specific?". These questions helped simplify and highlight desired GUI functionality.

The second prototype should aim exclusively to satisfy one primary task. We suggest that early prototypes be made task specific to minimize user-confusion and maximize individual GUI functionality feedback. This gives users a chance to better understand the abilities and limitations of newly customized GUI controls. We found that when users are subjected to too many new controls, feedback becomes more clouded and less detailed.

The second HCPS prototype included only GUI controls that helped Application Processors complete the primary task of analyzing an existing planning site. Users were provided with a flexible data retrieval mechanism to locate an existing site (Figure 4), and were given the necessary controls to perform and display analysis (Figure 5). Before these customized GUI controls were implemented, users would have had to learn several ArcView concepts (i.e. Select by theme), and numerous GUI controls; with the customized system these concepts are embedded into the functionality, and only one control needs to be learned. User-testing with the second prototype revealed that the system was indeed easy to use and understand due to the great many message boxes that appeared throughout the process. However, some users believed that these helpful messages could grow tiresome and reduce performance time for experienced users.

The third prototype should first address modifications requested of the second. This makes for steady and progressive prototype improvement. The third prototype should then focus on adding new GUI controls for the second primary task. Organizations or individuals who identify more than two primary tasks should keep building task specific prototypes until all tasks are represented on the customized GUI.

Usability tests conducted with the second HCPS prototype revealed that a new control to allow users to specify their familiarization with the system as either a ‘Novice’ or ‘Expert’ needed to be added to the third prototype. A User Expertise menu option was developed that contained a toggle menu item of "Novice" or "Expert". If Novice was selected the process would be less user driven and contain more message boxes, and if Expert was selected the user was given more autonomy and less instructions. Users could toggle between these settings in order for different planning tasks to be completed with the preferred level of assistance. This new control resolved the usability problem associated with the second prototype. Completion of this control allowed the design focus for the third prototype to shift to adding the necessary GUI controls for the second primary task: digitizing. A digitizing tool was created that permitted users to create a permanent record of submitted plans and then update plan attributes. The customized system allows this to be accomplished in two steps, using only one control, in comparison to eight steps and six controls required without customization (Table 4). User testing revealed that the third prototype successfully allowed users to complete all daily planning tasks easily and effectively.

Comprehensive prototype evaluations are critical for attaining a usable customized finished product. Three usability tests recommended by Macleod (1992) were used to evaluate HCPS prototypes: Analytical, Observational, and Survey.

Analytic evaluation methods are primarily based on specifications, and address fairly detailed aspects of the design (e.g. what functions the GUI should contain, and how these functions should appear on the GUI). Analytic evaluations are usually conducted early in the design process. This method evaluates usability before any actual design begins.

Usability tests at the HCPS were done with the Map Manager, and one other Application Processor after sketching the first prototype. Careful attention was paid to their reaction to menu names, button and tool icons, intended functionality of each control, and their relative placement on the GUI. The evaluation resulted in the construction of the first prototype that was met with approval. This test may be regarded as the catalyst for the success of the subsequent prototypes.

Observational evaluation methods involve "real people using working systems" (Macleod 1992). This method permits direct observation of end-users using prototype systems. To facilitate these usability tests, we suggest creating a set of mock tasks of typical system activities. The objective is to determine whether users can complete typical tasks with only the assistance of prototype specific user manuals.

The nature of the task presented with the second HCPS prototype involved locating a planning site by its Planning Application reference number, and determining what environmentally sensitive areas were within 150 meters of the site. This test was done by two planners, (one at Headquarters, and the other at a peripheral area office) and the Map Manager. This task was completed successfully by all three planners. All of them found and used the necessary controls to perform site analysis. Evaluative conclusions drawn from this test were that the second prototype was user-friendly enough to allow for the completion of one of the primary task specifications. The same method of testing was done with the third prototype, except this time, the task to complete was more complex, as it involved both task specifications (i.e. Digitizing and Analysis). The Evaluative conclusion drawn from this test were that the third prototype provided the necessary functionality to complete all requested planning tasks.

The merit of survey evaluation methods is that they give the evaluator "access to the users’ subjective views of the system" (Macleod 1992). We suggest Questionnaires as a survey method. Results from questionnaires can clearly illustrate where users feel prototype modifications need to be made, and what GUI controls meet with their approval. Questionnaire results can also serve as excellent consulting documents with subsequent prototype construction.

Questionnaire evaluations were distributed to all users after the second and third prototypes had been used. Overall planners were enthusiastic about how the third prototype operated as a whole. All the users agreed that the interface was intuitive, and that the functionality provided to complete planning tasks were easy to find, and produced the desired results. Everyone agreed that usability improved with each successive prototype, and that the third prototype allowed them to fulfill all their planning tasks.

This paper has described in detail how to effectively use rapid prototyping as a customization strategy to achieve a more usable and efficient GIS. Several techniques have been suggested for each of the three rapid prototyping stages, and examples of how to employ these techniques have been illustrated with the HCPS. Evaluative Usability tests reveal that we were successful in devising appropriate techniques to accompany the rapid-prototyping methodology to ensure improved usability results with customized systems.

 Many people contributed to the success of this paper. We would like to take this opportunity to acknowledge these people and express our gratitude. Jon Sheperd from the Highland Council Planning Service for giving us the opportunity to test the rapid-prototyping customization strategy. John Kenny from the Maine Department of Inland Fisheries and Wildlife, and Kevin J. Ingram from Geo-graphics Inc. for helping refine the paper. Our families who supported the endeavor from start to finish.

Aronoff, S. (1989). GIS: A Management Perspective. WDL Publications: Ottawa, Canada.

Cox, K., and Walker, D. (1993). User Interface Design Prentice Hall: London.

Davies, C. and D.M. Scott. (1994). GIS Usability: Recommendations based on the User's View. In IJGIS, vol.8, no.2, pp. 175-189.

Eason, K.D. (1984). Towards the Experimental Study of Usability. InBehavior and Information Technology, 3,2, pp. 133-143.

 Eberts, R. (1994) User Interface Design, Prentice-Hall,Inc: New Jersey.

 Lindgaard, G. (1994). Usability Testing and System Evaluation, Chapman & Hall: London.

Macleod, M. (1992). An Introduction to Usability Evaluation. InNational Physical Laboratory Report DITC 202/92, pp. 1-31.

Medyckyj-Scott, D. Newman, I. Ruggles, C. Walker, D. (1990). Usability Testing in User Interface Design for GIS and the Role of Rapid Prototyping. In EGIS 90, pp.737-745.

Medyckyj-Scott, D. (1993). Designing Geographical Information Systems For Use. In Human Factors In Geographical Information Systems, Medyckyj-Scott, D. and H. M. Hearnshaw, (eds) Great Britian: Belhaven Press, pp. 87-100.

Newman, W. and Lamming, G. (1995). Interactive System Design, Addison-Wesley Publishing LTD:Cambridge.

 Scott Cattran

Consultant, Programmer

Geo-graphics Inc.

15 Cheltenham Ave.

Toronto, Ontario, Canada

M4N 1P6

Voice: (416) 481-6277

E-mail: Scattran@geo-graphicsME.com

Dr. William Mackaness,

Lecturer in Geography

The University of Edinburgh

Drummond Street

Edinburgh, EH8 9XP

Scotland

Voice: 0131 650 8163

Fax: 0131 650 2524

E-mail: William.Mackaness@ed.ac.uk