The contributions of human factors or usability practitioners to application development often begin with a functional specification handed down from an external source. User-centered design methods are commonly applied to how function is delivered but not what functions will be delivered. We in the Interactive Transaction Systems (ITS) group at the T.J. Watson Research Division of IBM have succeeded, during several application development efforts, in expanding the scope of our user-centered, iterative design approaches to include functional as well as interface definition for both software and hardware (kiosk/workstation) design. By learning our customer's business and owning the entire development process, we can better design our solutions to solve their problems (and their client's problems in the case of service industry solutions). We achieve this by including the functional definition in the first of four phases we have defined for all of our development projects.

A significant facilitation for this in the arena of software development has been the CADT (Customer Access Development Toolset) development platform we use to build our applications. This set of tools for iterative application design and development gives us the flexibility to quickly and effectively address emerging functional requirements.

Students in human factors design courses have long been taught that a successful designer must begin by stepping back and taking a systems approach to defining the problem and subtask suite to which a technological solution will be applied (c.f. Chapanis, 1970). This perspective has a traditional importance, predominantly in supporting allocation of functions or tasks to humans or to automation (McCormack, 1976). All too often, however, a human factors design group is brought in after the overall functional specification for an application has been determined, sometimes by a marketing division, sometimes by the customer. This paper describes a four-phase process we have evolved to bring human factors considerations and continuing user participation (Holtzblatt & Beyer, 1995) to all aspects of functional and interface design.

We have evolved a four-phase, iterative process for developing and delivering software applications, based on the four basic principles of usable system design (Gould, 1987): early and continual focus on users, integrated design, early and continual user testing, and iterative design. The four phases we use are:

1. Discovery: Learn customer's business; Establish user-constituencies; Teach customer about capabilities of our technology; Establish initial functional specification; Establish value (if any) of proceeding for each constituency.

2. Proof of concept: Quickly bring customer a proto-application stub to bootstrap the application.

3. Pilot iteration: Build initial, coherent application in concert with continuing user testing.

4. Application rollout: Enterprise-wide delivery of fully functional system; continue iterations of function and interface after delivery.

Each of these phases brings value to our customers and it is not uncommon for us to establish a remunerative contract for each phase. However, it is the sum total of all of these phases that make for a successful application.

This paper describes the expansion of the scope of Human Factors contributions into the area of functional specification. Six example (four kiosk-based and two desktop workstation) applications are used to illustrate how we have brought this idea into practice:

Human factors practitioners are integral members of our development team from start to finish; they join in a thorough task analysis at project inception. It is crucial to go to the customer and really understand the business environment from the perspective of an "operational" or domain expert, and not just as a "technical" expert (Wallace, et. al, 1995). Application development can only be truly successful if it addresses a real problem. Ideal customers recognize that they have a problem and that they want to solve it; their desire is great enough that they are open to new and exciting solutions.

Often however, customers will not fully understand the problems the design team has been approached to solve or won't appreciate the extent to which technology can address their problems. The developer's job here is to make effective "value propositions" to each of the affected user groups or constituencies, to show how the proposed technology will make their job faster, more effective (and more fun). not just to deliver

We begin the discovery phase by understanding the constituencies on whose behalf the development will proceed. Each brings a new perspective to the functional definition. In our engagements with customers on the EMS, Touch Illinois, NYPL, and AMNH projects, we have developed the following generic set of constituencies.

• Customer -Corporate entity that hires us.

• Champion -High-level executive at Customer who believes in us and in the mission we undertake.

• Executive -Customers who make go/no-go decisions about project; in the best of worlds, the Executive is also the Champion.

• Supervisor -Manages work of staff; often has come up the ranks from staff position; often no longer works directly with clients, but has domain expertise based on the old way of doing things.

• Staff -Customers who currently do the work the old way with clients.

• Client -End users of application ("customers of our customer"). In client-user applications, there are often interfaces used by staff with support/management functions (and styles) that differ from the ones used by clients.

It is critical to gain executive support for the developer's requirement to have full access to all constituencies; we cannot derive a valid idea of client needs and perspectives by proxy.

In the Auto Finance project, we used a proprietary consulting methodology based, in part, on the work of Winograd & Flores (1987). We derived a more complex, three-tiered taxonomy, specific to that customer. The "bank" tier comprised executive, legal, marketing, finance, and information services roles; the "dealer" tier consisted of owner/general manager, finance, sales manager, sales, and office staff; the third tier was "consumer".

As we penetrated each layer of our constituency, new functional requirements came to light. Executives at our first banking customer for Auto Finance first became interested in our work after seeing a demonstration of Touch Illinois. Database-assisted input and other interface techniques opened up the possibility of more accurate end-user data entry, moving this task out into the field and decreasing loan approval turn-around time. The Information Services department saw an opportunity to have loan application transactions formatted in the field eliminating bottlenecks in workflow. Dealer general managers wanted same-day funding to improve cash flow. Dealer Finance folks saw 5-minute loan commitments streamlining back-office functions, but insisted on an open system that would connect to an arbitrary number of lending sources. Sales staff envisioned a more effective tool for closing sales.

Some sales managers wanted the system to be usable by the consuming public (who saw it as a less-threatening way to deal with the personal matters in loan applications), and other sales managers wanted to "own" the loan interface in order to increase "face time" with customers.

The point of this example is that the developers must persist in efforts to gain full access to all the layers of constituency all the way up to the level supervisor/staff if all useful potential function is to be uncovered. To each constituency, the value added by the proposed application is specified and each constituency is included as partners in development; this has the nice side-effect of building a broad base of support for continued development phases.

During the first phase of the AMNH project, the Executive introduced us to heads of all the departments she thought would have an interest in the visitor way-finding kiosk application, not just the department currently responsible for this function. We approached each interview in an open way to learn as much as we could about each department's tasks. We asked questions about what, of the existing work, was repeated, mundane, or difficult. Implicit was the assumption that there were technological solutions possible in the proposed application. In the process, we developed a long laundry list of potential functions and established "advanced publicity" in different quarters for the application still-to-come. We also learned things that had direct impact on the core function from unexpected places. The Events Manager informed us that certain exhibits and hallways are blocked off from time-to-time (a definite impact on way-finding!) which would require moving the kiosks (wheels suddenly a must) and notifying visitors (dynamic updating of pathfinding algorithms).

One key to a successful customer engagement is getting a sufficiently high level executive on board as early as possible. This application champion must be enthused about the project and must have a sufficient ego stake in the outcome (and confidence in the developers) to sustain the project throughout all the phases. In the EMS project, our champion was a high-level executive in the Corporate Procurement division who was able to open doors for us (sometimes literally during site maintenance visits!). Customer champions are not always corporate executives; in the Touch Illinois and Expo ''92 projects our champions were political appointees.

In client-user applications, support of staff roles is particularly important. If they feel threatened or out of the loop, they can block access to clients or otherwise make life difficult for developers. We were fortunate in the Touch Illinois project to have staff members on board early on (they were key contributors to the functional design and had a significant interface component of their own in the final application). In AMNH, the museum staff (guards, information desk volunteers) helped us gain access to the ultimate end users -- the visitors. They also helped us learn about the questions most frequently asked by visitors. Again, these were critical inputs for the functional design and content of the application.

In network-centric, transactional applications such as the ones described here, it is also vital to gain the support of the Information Services or Data Processing department. We have to be sensitive not only to the impact our application will have in front of the screen, but also to the impact this technology will have on the folks maintaining legacy (existing/previous generation computing) systems behind the scenes. Often, active support from Information Services groups is required to get the application working, sometimes in ways that show no obvious direct benefit to the existing Information Services functions. We have been fortunate to get lots of proactive and patient Information Services support in Touch Illinois and EMS projects including advanced notice of upcoming changes in legacy systems to which we were connected, after-hours help in setting up special userids and network gateways, special insights into pitfalls and quirks in existing database update procedures, etc..

In addition to understanding the taxonomy of user constituencies, it is important to develop an understanding of the political ecology in which these roles exist; turf wars and other interactions among roles can have an impact on application design.

The primary information-gathering techniques we use in the discovery phase are one-on-one (or few-on-few) interviews and informal critical incidents. Principles of contextual inquiry (Baecker, et. al., 1995) and apprenticing with the customer (Beyer & Holtzblatt, 1995) guide our efforts to fully understand our customer's needs apart from whatever technological impediments may currently be in place. As an example, one of the tasks undertaken by developers in the Touch Illinois project was to learn how to fill out the paper-based unemployment application forms.

For public-access applications, the site-walk is crucial; this is not a guided tour with executives or staff, this is an independent, in-depth walk-through where developers observe client-users in the target environment.

The AMNH site-walk taught us many things about the ecology (graphical and social) in which our application would exist that we could not have learned effectively in back-office interviews. As an example, our team heard seven different languages spoken by visitors at the museum, we made note of color schemes used in existing signs and banners, and we learned about the different physical constraints our kiosk and application would have to operate under (lighting, noise, traffic flow patterns, etc.).

We don't use them. More accurately, the functional specifications for the applications we develop are embodied in the applications themselves. Rather than write the emerging functional requirements down on massive amounts of paper, we code them right into the emerging application. This saves time in authoring, review and approval of documents (which have no value in themselves); this also shortens our iteration and delivery time tremendously. It also provides a much clearer portrayal of the proposed functions since the specification is in the "language" of the ultimate implementation of those functions. This, of course, only works if the development platform supports it.

The primary outcome of the discovery phase is, instead, an informal list of possible functions; a small number of which will be encoded in the bootstrap proto-application delivered in the next phase. This list will be added to, prioritized, and implemented in the pilot iteration phase.

One non-trivial outcome of the discovery phase is the decision on the part of the designers on whether or not to proceed with the engagement. An example might be a customer who, for political or other reasons, has a rigid requirement for a glitzy-looking lobby kiosk and is not interested in uncovering and meeting real needs of any particular group of users. Another example might be that, after considerable dialog in the first phase, a customer still underestimates the capabilities of his or her clients to accomplish meaningful work on a well-human-factored application and resists commitment to a truly useful product. We have learned that we must be prepared to walk away.

In this phase, we bring the customer a functioning proto-application to demonstrate the key concepts. This coinage of "proto-application" is a studied avoidance of the term "prototype"; the latter implies a function-impoverished model of an application which will be discarded once the "real programming" begins. We believe that a substantial improvement in effectiveness is gained through the use of a development platform that supports iterations on the deliverable code base. This quick demonstration helps the customer application champion to "sell" the idea broadly within the organization. It is important that the development platform enables delivery of a proto-application early (i.e., within hours or days, not weeks or months) in order to guide the customer's expectations. In Expo ''92, we quickly created the proto-application that was demonstrated to high-level executives in late 1989 -- 2.5 years before opening day. This served to excite the customer and gain political support for the project throughout the various constituencies involved.

As soon as the project is proposed and the functions begin to be uncovered, the customer is going to have a heightened awareness of related technologies, some of which may not be appropriate for solving their immediate needs. Seeing our technology transposed into their domain gives them a framework for thinking about how technology can be applied to their problems and can generate ideas that go beyond the boundaries of the previously existing task.

After working with the proto-application, the customer is equipped to begin prioritizing the ideas generated in the brainstorming portion of the first phase.

An early application stub is also a vehicle for establishing contact with end users (clients). Preliminary, isolated explorations of interaction techniques can begin here, in advance of iterative development (where techniques are employed and studied in the context of the actual emerging application). We have been successful using traditional human factors techniques (c.f. Shneiderman, 1980) in this context. An example of an independent orthogonal study which spun off from an earlier online timecard project can be found in Kelley & Ukelson (1992). An example at NYPL was an early test of some soft keyboard designs for library patrons, that population comprising more sophisticated keyboard users than users of previous ITS kiosk soft keyboards. We found a requirement for keyboard layout and function that more closely matched what is found on mechanical, QWERTY keyboards. (An interesting anecdote of this small study was that, during preliminary tests of a sub-function that collected people's opinions, we found our first requirement for an exclamation point on our soft keyboard!)

By iterating the design on an installed application, we maintain a vehicle for continuing discussion of the emerging functionality (and interface design) with actual users or clients in the actual environment of intended use. In the Expo ''92 project, there were many challenges we had to face concerning the design of the kiosk hardware for use in the hot, Mediterranean sun and in the design of usable, useful functions for a multi-national user population. We had two proto-applications installed at the Expo site fully two years in advance of the opening of the Fair. In fact, when we installed our first model kiosk, there was nothing on the 2 square-mile site except dirt and a visitor's center. This didn't stop busloads of tourists from coming by to see the construction however. We stationed a developer/experimenter at these sites and the Expo staff would shepherd people over to use and comment on our kiosk information system.

Our experiences with client-user applications show that the staff often learns new things about clients (and about the job they are doing with clients) at the same time we do. This is where the customer can develop confidence in the client's ability to accomplish meaningful transactions with little guidance; this often comes as a pleasant surprise to customers who, we have found, often underestimate the capabilities of their clients.

Customers who may initially underestimate the capabilities of the developers also begin, in this phase, to learn the real value-potential of the application. At NYPL, we began our iterations on a terminal reservation function to replace a burdensome, paper-based process that was a bottleneck for librarians. We argued that this sub-function immediately replace, not supplement the old method. Staff soon learned that this worked and saved them and their patrons time; pressure soon followed to propagate this application throughout the library.

Iterating on function does not only imply modifying or adding function. In the NYPL pilot, in addition to adding a fast reservation path to meet observed client needs, we ended up dropping a database display-ordering interaction. Although it seemed like a good idea when it came up in the brainstorming part of the discovery phase, we observed it to be an impediment to users with domain expertise.

It is important to get proto-applications in front of users and begin doing design work in the field as soon as possible. ITS developers at this juncture can frequently be heard reminding each other of our prevailing philosophy: "Make it Work, Make it Good, Make it Great". Aside from bringing focus to discussions about nuances or future functionality, this also expresses the confidence that our methodology and CADT development tools will be there to support refinements and the ultimate pursuit of quality.

The usefulness of an application relies on the currency of the content. It is crucial to design (and iterate) the content management functions so that these can be effectively owned by the customer and easily updated. It is also crucial that the application be fully integrated into the customer's workflow; if the new solution is perceived as being difficult to update or as requiring extra work to incorporate, there will be pressure to retire the application once active participation on the part of the developers winds down.

It is important to point out that functional and interface development does not stop when the full application is shipped. There will usually be ecological implications to the introduction of the new technology that cannot be anticipated. In addition, new customer problems may arise that can be solved readily by adding function. In Expo ''92, after the fair began, the Expo administration requested the addition of a function to display a daily lottery. This was a case of the customer requesting a functional change after learning about the flexible nature of our development platform.

It is for this reason, among others, that we don't speak in terms of "releases" of applications since that implies that teams of programmers are tucked away in labs busily working on improvements and fixes. Rather we think of the application in the field as a living organism, continually susceptible to growth and evolution. Supported by the right development tools, this can either be driven by the original developers or the customer's Information Services staff can be empowered to own this phase in the application's life.

Maintaining an openness to new and evolving functionality requires a development environment and toolset that supports flexibility without sacrificing reliability.

CADT, the IBM Customer Access Development Toolset for OS/2 and Windows is a set of tools (Wiecha, et al, 1990) developed in the ITS group which enable cooperative development of transaction-based, highly interactive applications. The fundamental concept behind the CADT tools is the division of the task of application development into components of style and content. This division facilitates the addition, subtraction, and modification of function independent of specific stylistic aspects of the interface. The division in the tools between style and content specification also facilitates cooperative development of applications with contributions from a multidisciplinary team (with varying skills) as well as generous code re-use and the ability to iterate development under a user-centered model of Research in the Marketplace.

By following the principles outlined in this paper, human factors practitioners in the ITS group have been successful in meeting not only the usability needs of their customers, but also in meeting their functional needs, both those that were known, a-priori, and those that needed to be uncovered. The key principles are:

You are visitor number: