instituting integrated workflow...

58 i n t e r a c t i o n s . . . j a n u a r y + f e b r u a r y 1 9 9 9

Instituting IntegratedWorkflow DevelopmentInstituting Integrated

Workflow Development

J O H N I M S P H . D . , C P E

Robin Jareaux ©1997 Artville, LLC

DDST Systems, Inc. provides information processing and computer software services and prod-

ucts primarily to mutual funds, insurance providers, banks, and other financial organizations.

In the early 1990s, DST developed a state-of-the-art OS/2 Integrated Work Station™ (IWS®)

that achieved better work quality and improved training time compared with equivalent 3270

processing applications. Today, the financial services industry uses DST technology to respond

to more than 30 million shareholder calls per year. In 10 years, that number could triple. Tak-

ing what we have learned about responding to shareholder inquiry and transaction calls, upper

management (in tandem with our clients) mandated a new TA2000® desktop that further

improved the integration, efficiency, and productivity of operator activity flows.

59i n t e r a c t i o n s . . . j a n u a r y + f e b r u a r y 1 9 9 9

a r t i c l e

TA2000. Generally, the interfaces differed intheir presentation, navigation, layout, andlabeling as a result of their respective productdevelopment histories. Perhaps a more impor-tant issue was the way in which operator tasksextended across applications. Initiating anaction in one application often required anoperator to remember to finish the task inanother application.

The video showed a processor sitting infront of her workstation taking a phonerequest from a shareholder. A clock was super-imposed on screen to show elapsed time tocomplete the shareholder request, a devicethat illustrated to the audience the complexityof the desktop. Watching the processor navi-gate between applications and among win-dows within an application in an attempt tominimize time spent on the call was concretein illustrating the meaning of integration andencouraging discussion of the needs of busi-nesses and operators. Some audience memberssaw an opportunity to make learning easier.Even experienced operators found it difficultto know how to use the current system. Oth-

TA2000 is the most widely used shareholderrecord keeping system in the mutual fundindustry. Performing the accounting for morethan 48 million shareholder accounts, it deliv-ers extensive functionality and support forevery facet of the mutual fund industry’s full-service and remote operations. TA2000 is amainframe system with many alternativeaccess points (telephone, Web, workstations).The opportunity to rebuild the user interfaceof the TA2000 workstation evolved from theexecutive decision to switch from OS/2 (thecurrent platform) to Microsoft Windows NT.Thus the door was opened to address work-station interaction issues.

Getting StartedIn April 1996, one of our corporate officersrequested a workstation processing visionbrainstorming session. I was selected as theevent facilitator. The session, which lastedone afternoon, was designed to list and orderclient issues involving the integration of ourworkstation products. The chief informationofficer (CIO) and his direct reports as well asseveral senior client staff attended.

We began our discussion byshowing video clips of actual call-center processing interactions. Fig-ure 1 is a schematic of typicalcall-center processing interactionsas they are handled on our currentOS/2 platform. A shareholder maycall to request information oraction on an account. The associateinterprets the request, accesses orchanges the information throughone or more TA2000 applications,and responds. The operator thenrecords the processing action usingan image-enabled work manage-ment system.

As shown in Figure 1, the work-station applications used by opera-tors involved multiple userinterfaces. The interfaces wereeither mainframe (3270 based),graphical (GUI), or both. TheAutomated Work Distributor™(AWD®) is a separate DST prod-uct that is used in conjunction with

John Ims

DST Systems, Inc.

1055 Broadway, BW09

Kansas City, MO 64105

+1-816-435-5398

Fax: +1-816-435-4440

[email protected]

http://www.dstsystems.

com

Figure 1. Call center processing schematic. Customer contacts call center associ-ate, and associate accesses several TA2000 applications to address customers’requests. The Automated Work Distributor provides image routing capabilities(e.g., letters, forms) and manages the work flow across the call center. Applica-tions are all available through the same imput-output devices (keyboard andmouse control); however, each has its own interaction style, and there are fewsupportive connections (e.g., operator must re-enter data, interactions in oneapplication may not reflect actions taken in another application).

has made good use of a large variety of theavailable links (e.g., facilitated teams, busi-ness analysts that mediate between users andprogrammers, support lines, surveys, usergroups, and trade shows). When human fac-tors was introduced to DST, these links weresupplemented with more direct links [2] suchas contextual observational studies, operator-interface prototyping, and formal usabilitylab evaluations.

For one showcase pro-ject, the confluence of (1)our decision to adopt theNT platform for our GUI;(2) the desktop visioning foran integrated, unified, andconsistent interface; and (3)the introduction of contex-tual design methodsoccurred at an opportunemoment. The CommonBusiness Object (CBO)team had been laboring tocreate a set of objects thatsupported the separation ofthe TA2000 operator inter-face from the core businesslogic and the data. Separa-tion of the two provides forthe reuse of both operatorinterface software andCBOs in a variety of work-

station products. One difficulty encountered by the CBO

team was a result of their focus on objects.Since TA2000 exists as a mainframe productwith operator interfaces on both 3270 andOS/2 platforms, the team had ample codeavailable from which to abstract business rulesand develop objects. However, the team hadbeen working without any NT platformvision for the operator interface layer. Further,the team was working without a direct linkrevealing how operators used the current sys-tem. One might imagine a group of peoplewandering the countryside analyzing the pur-pose of gas cans without any concept of a car.It became clear that development of CBOsmust be conducted in the context of productuse. This required creating a vision of a workflow and its associated operator interface.

ers saw a need to improve the efficiency ofdata processing. The rest recommended a sys-tem that resulted in fewer errors.

The Desktop Vision session produced anumber of guiding principles that influencedthe design and development methodology ofthe new interface:

✖ All DST products will be integratedand have a unified, consistent interface.

✖ They will have the same “look andfeel” supported bycommon interactiondesigns.

✖ Operators will be ableto move seamlesslyfrom one applicationto another withoutrealizing they areworking with differ-ent products.

✖ Reduced keyboard ormouse actions will bea goal for every pro-ject. Windows will bedesigned to ease theuse of keyboard andmouse.

✖ All applications willsupport novice andexperienced operators.

✖ Product or projectdesigns will be drivenby work flow analysis. Our projectmethodology will emphasize iterativeusability evaluation.

✖ GUI corporate standards will shapethe development of all operator inter-faces.

There were many more functionally specif-ic guidelines, and all served to encourage whatwas at that time a new paradigm for DST’soperator interface development process—specifically, increasingly direct contactbetween the interface designers and the inter-face users.

Keil and Carmel [2] described a cus-tomer–developer link inventory. They usedthe inventory to support the belief thatgreater customer participation can lead tomore successful software projects. As a suc-cessful software vendor for many years, DST


One might imagine a

group of people

wandering the

countryside analyzing

the purpose of gas

cans without any

concept of a car.


a r t i c l e

Many details of work strategy are often for-gotten or are never explicitly realized. In orderto integrate work processes, the team needed away to make the work activities more visible.

In-context work observation became thetool of choice to bridge the knowledge gapand focus on operators’ needs. For BAs, thetransition from being active interpreters ofusers’ needs to observers of users’ actions andstrategies was not always easy. Observational

sessions require a morereflective, interpretive per-spective. We followed anapprenticeship model [1] inwhich the operator is theexpert and the observers arebeing tutored. Thisapproach requires a changeof attitude and a focus onthe intent, strategy, con-cepts, and structure of thework activity. Team mem-bers found it easier toobserve and documentwork practice and struc-ture; they had to learn toask about and observe workintent and strategy.

To develop observer skillsets within the team, Iintroduced vendor courses,gave many small group

learning sessions, brought new team membersalong on observation trips, and most impor-tant, practiced with the team to improve ourobservational and analytical skills. Practiceinvolved multiple observation sessions atmultiple sites. After each site visit, teammembers gathered to tell each other the“work stories” that were observed. Timing isessential, because memory of observationaldetails (especially work context) is quicklylost. Early sessions inevitably led to morequestions. By iterating observations withanalysis, team members improved their obser-vational skills. The more experienced theywere in anticipating questions encounteredduring analysis, the more refined the observa-tions became. As the project grew, so did thenumber of BAs. Experienced BAs wouldmove on from analysis to design (Figure 2),

Learning How to Characterize the Real WorldMay 1996 marked the beginning of theTA2000 workstation design and developmenteffort using contextual analysis techniques.According to the desktop vision approved byexecutive management, the main criteria forsuccess of the GUI focused on improving theusers’ work activities. Of course, this requiredunderstanding operators’ current activitiesand generating creative ideasfor improvement. Initial datagathering techniques consist-ed of

✱ Videotaping (showingothers what we saw),

✱ Survey taking (askingusers what data andactivities they thoughtwere most importantwithin a work flow),and

✱ Contextual observa-tion (sitting next to acall center associateand recording what wesaw and heard).

The technical team alsoran mainframe queries toidentify which applicationsand functions on TA2000were most often accessed. Weused these data to identify common workflowsequences (what is done?), workflow influ-ences (why that way?), and roadblocks to effi-ciency.

The observation sessions represented a newapproach for our business analysts (BA). For-merly expert operators, they have been pro-moted from the processing work force into thedevelopment work force. Typical job require-ments of BAs are to define and interpret userneeds and requirements to technical teams,answer client inquiries about system use, andverify new system functionality. BAs rely ontheir system experience, system documenta-tion, and a network of knowledgeable expertsto complete their assignments. Unfortunately,there is often a significant difference betweenwhat people remember about their work expe-rience and how that work was accomplished.

Team Members

had to learn to

ask about and

observe work intent

and strategy.

create use cases for object development andstoryboards for GUI navigation design,which in turn were used as scenarios forusability evaluations (Figure 2). As each ana-lytical session built upon another, everyteam member had the ability to recite a vari-ety of core workflow stories. Group under-standing of how work occurred wasextremely valuable to the creation of ashared vision.

Designing a New Operator Interaction LayerThe design process progressed from work-flow observation to workflow design to sto-ryboarding a new navigation structure.Figures 3 and 4 illustrate the vision thatresulted from workflow analysis. Conceptu-ally, the new vision simplified the operatorinterface by collocating data and functionsthat naturally go together as part of a work-flow. We used the workflow analysis to iden-tify these linkages and to identify integrationpoints, that is, places where one task neededto easily flow into another. From an inter-

face design perspective, integration pointsevolved into navigation pathways or branch-ing controls available in the GUI. We evolvedthe redesigned work and the high-level UI viastoryboarding. The storyboard was iteratedusing the work scenarios that were observedduring data gathering. Ultimately, these story-boards became the UI screen flow or naviga-tion structure.

One example illustrating the benefits ofcollocating data and functions is illustrated bythe account details window. The accountdetails window is the base screen in the appli-cation. It presents an overview of a sharehold-er’s account relationship with the mutual fundmanagement company. We designed this win-dow to contain up to 80 percent of the infor-mation requested in a typical shareholderphone inquiry. Key data fields on this windowevolved from our observation sessions. Duringeach inquiry call, we observed operatorsreviewing maintenance actions on accountsfor recent address changes (important forfraud detection). We also noted that share-holders and dealers often call to confirmrecent financial transactions. We collocated

but there was always enough experience with-in the core observation team to mentor thenew members.

One team member described the analysisprocess as “tribal.” Essentially, the designgroup sat around a table and told workflowstories. At first the stories were observed workactivities. Over time, the stories evolved togeneralized work descriptions. During theanalytical sessions, workflow scenarios wereredesigned if the design team saw a way forimproved efficiency (such as eliminating man-ual steps) or the addition of new functionali-ty. For example, we observed that paperhandouts and forms are used throughoutoperational environments for real-time fundmarket announcements (fund managementchanges, fee changes, fund dividend datesetc.). To support this need, we added intranetbrowser technology to the interface, creatingan electronic bulletin board for operationalmessages.

Analytical sessions illuminated opportuni-ties for system improvement. They also illus-trated holes in our understanding of workactivities. We used new workflow designs to


Figure 2. The project methodology incorporated both the elements ofObject Oriented development and the human factors process. To date,this has been a 2-year project with more than 600,000 lines of code gen-erated and a development team size of more than 40 people. At any given time, all phases of development (data gathering, analysis, design,testing) occurred simultaneously for different functional deliverables(inquiry, maintenance, financial transactions, and new account setup).

high-use ownership, maintenance, and finan-cial data within one window to reduce opera-tor movement or navigation through theinterface. Collocating data and functions thatare related to workflow garnered many posi-tive responses from operators. Commentsfrom operators who used the interface fre-quently included these phrases: “I like theaccessibility,” “It is useful having pertinentinformation on one screen,” “I enjoy that theinformation is in the same logical order as thecall,” and “It seems to be presented just as theflow of most calls would be.”

Figure 4 illustrates the evolution of a newaccount setup (NASU). Workflow analysisdemonstrated a close link between accountmaintenance and NASU. Both included therequirement to enter or change accountdescriptors (joint, single, IRA, etc.), owner-ship and registration descriptors (name,

address, age, etc.), and account options andattributes (bank instructions, systematicinvestment choices, alternate addresses, etc.).Very often processors would model or copy anew account from an existing account andchange it as necessary. The new vision broughtthe interaction design of the two processescloser together and took advantage of thesame window controls and navigation path-ways.

Work sequence descriptions became moredetailed as we incorporated additional contex-tual interview data. (See Figures 4 b and c.)The schematics were useful in comparing andcontrasting different client work structures.Generally, our analysis noted a similar processregardless of the work environment. In part,this was because all clients were addressingsimilar customer needs (shareholders and theirmutual fund business) and all clients were


a r t i c l e

Figure 3. Our vision for the new call center processing schematic. A customer contacts the call center associate. Theassociate accesses a variety of applications to address the customer’s requests but is unaware that separate TA2000applications exist. Data sharing and cross-application workflows are supported. Automated updates to AWD are sup-ported. Interaction styles across functions for form filling, file maintenance, inquiry and processing functions are con-sistent and support fluid transitions within and between work sequences.

using the same basic technology (DST’s soft-ware suite). Still, exceptions existed and wereoften represented as conditional branches onthe schematic.

The design team used the detailed work-flow schematics and window storyboards toevaluate the success of the design concept. Atfirst, we evaluated the most frequent path or“happy path” using typical work scenariosobserved during data gathering. We modifiedand re-evaluated the design whenever it couldnot accommodate a particular scenario. Wecontinued this cycle of design evaluation andmodification using more unusual or less likelyscenarios. This was a very fast evaluationcycle. Evolution would occur several timeswithin the span of a three-hour design session.The team used white boards and sticky notesto represent design ideas. Designs drawn onwhite boards are easy to change. We stoppediterating when the interaction design was lessfragile and when we could address 80 percentof the work scenarios. Improving 80 percentof the work gave us the biggest bang for thebuck and avoided the inevitable “analysis


Figure 4. The evolution of a new account setup activity. (A) Observed workflow steps from one operator at one partic-ular client site. Several applications are in use. Several manual actions are also represented. (B) The linear workflowsequence is abstracted to several simple steps. The abstracted NASU sequence is not unlike creating a new documentin a word processor. Operators are motivated to make use of any information that already exists. Copying from anexisting document and modifying it as needed keeps information in synch and reduces re-entry. It is also faster thanstarting from a blank form. (C) The workflow schematic is elaborated and enriched with detail in order to handleexceptions. It now contains conditional branches. (D) The beginnings of a storyboard. The workflow is mapped to aschematic window sequence or user environment design [1]. The application image contains the source material. Basescreens for the application are the Search and Details windows.

A

B


a r t i c l e

C

D

Through consultation, advice giving, direc-tion, and mentoring the GUI design teaminstilled in each BA the insight, skill, and con-fidence to own the operator interactiondesign.

Once a UI structure was established, theteam developed high-fidelity, detailed windowdesigns in a prototyping tool. Having detailedwindow designs available helped the team dis-cuss window layout, control, and labelingissues. One of our goals was to reduce trainingtime, so the team was sensitive to DST’s tech-nical jargon, and where practical, replaced it

with more understandableterms. We decided to keepthe high-fidelity prototypecode distinct from our appli-cation code. The prototypewas used to explore and eval-uate UI concepts and ideas.Keeping prototyping andapplication development sep-arate, reduced-the-all-too-frequent temptation toimplement an incomplete oruntested design idea. As theinterface concepts evolved indetail, the fidelity of the pro-totype increased to becomefully interactive. As describedby Rudd, Stern, and Isensee[4] we took full advantage ofour low- and high-fidelityprototypes. Low-fidelity pro-totypes (paper screens) were

used to evaluate design concepts, and addressstructure issues. The high-fidelity prototypewas used for evaluation, served as a livingspecification, and was used repeatedly todemonstrate the interface concept. The pro-ject team gave multiple demonstrations tonew and existing clients several times amonth throughout the development phase.Demonstrations served as another source offeedback and the responses we got helpedkeep us focused on the needs of the user com-munity.

Using Feedback To Iterate DesignAt critical points in the design process, wesought feedback in order to measure our suc-

paralysis” that results from designing for everyevent.

Protecting the integrity of the integratedworkflow structure and maintaining consis-tency as detailed development of windowsprogressed was a challenge. The number ofwindows required in the interface was toolarge to be the sole responsibility of any oneperson (currently, there are approximately 200windows). Separate teams of programmersand BAs were assigned responsibility for well-defined functional areas. The BAs were direct-ly responsible for the interaction design.According to the directionof the project team leader,programmers made no cre-ative screen design changeswithout consulting the BAdesigner. Early on, the BAswere not experienced win-dow designers. A mentoringprocess was established toassist them in translatingtheir concept of workflowinto detailed windowdesigns. To develop designskills within the team, weagain introduced vendorcourses, gave small grouplearning sessions, broughtnew team members intoongoing design sessions,and, most important,formed a core GUI designteam.

The membership of the core design teamincluded myself, for human factors skills; twoBA workflow experts; an application program-mer; and a rotating (new) member. The GUIdesign team produced the high-level windowdesigns and determined the major navigationcontrols. The details of these high-level win-dows were then completed by the responsibleBA (the rotating member). Learning how todesign was a shared experience in learning bydoing. On any given day, the design teamwould review details of a completed detaileddesign for workflow and window consistency,develop a high-level design for a new set offunctions, or participate in a work modelanalysis session for future functionality.


A mentoring process

was established to

assist the BAs in

translating their

concept of workflow

into detailed

window designs.


a r t i c l e

and design decisions. Perhaps most impor-tant, they were exposed to the user interfacedesign methodology and development successcriteria. This was particularly helpful duringthe usability evaluation sessions becauseclients would volunteer to send their process-ing personnel to our facility to get hands-onexperience with prototype versions of the soft-

ware. Clients were also givenour high-fidelity prototypeto “try before you buy” intheir own environment.These participatory experi-ences encouraged clients tosupport our efforts to intro-duce contextual design andanalysis methods through-out the DST developmentorganization.

Hindsight

ChallengesDST is a technology servicecompany. In that role, itmust be responsive to itsclients’ requests for modifi-cations and enhancements toits software and services.Clients’ requests are commu-

nicated through management and can be quiteremote from direct-user experience. For manymonths, the team had Neilsen’s [3, p. 14]advice posted to the door of our analysis room:

Vice presidents and other corporate executivesshould realize that they are no more representa-tive of the end users than the developers are.…[Vice presidents’] “intuitions about what wouldmake a great design may not be accurate.”

Confronting powerful intermediary cus-tomer links from within a service companyenvironment is challenging. At times, despitewhatever workflow-based evidence or analysiswe had, sometimes we adjusted our designs tomeet the goals of executive managementrather than our perception of users’ needs.Competing priorities is a typical phenomenonin all development projects. Our relativelynovice BA team was challenged in knowinghow to question and evaluate particular inter-action design change requests.

cess. We followed the same strategy that wasfollowed on the initial data gathering effort.We had real users perform typical work sce-narios on paper versions of our windowdesigns and later on the more realistic dynam-ic prototype. The evaluation scenarios weregenerated from the workflow design. Thesame mentoring approach to train the BAswas used during the evalua-tion cycles. BAs were taughtto use the same data-gather-ing techniques duringusability evaluations as wereused in the field beforedesign. In many cases wealso recorded operator inter-actions in order to conductmore formal usability dataanalysis. We often showedclips of these videos to theproject team in order tocommunicate both our suc-cess and challenges. Ourergonomic success criteriawere applied to the evolvingdesign to ensure that wewere improving the operatorinterface through

✦ Increased efficiency,measured by countingsteps in the process, number of win-dows, number of keystrokes or mouseclicks, amount of time to complete anaction.

✦ Improved quality or fewer errors, mea-sured by the operator’s ability to1. Anticipate the next step in an activity

(what are you looking for?, what do you think will happen next?) and

2. Detect and recover from an error.✦ Reduced training, measured by number

of trials to performance criterion✦ Satisfaction, measured by rating scales

on perceived efficiency, learnability,and task flow acceptability.

Our client partners also provided feedbackon the success of the design. Through the firsttwo years of design and development, projectmanagement held regular monthly meetingswith key business clients. The clients helpedput in priority order and evaluate our analysis

Clients were also

given our high-fidelity

prototype to “try

before you buy” in

their own

environment.

It is common to hear someone say, “I havebeen designing screens for 10 years; I knowwhat is best.” People are not always comfort-able accepting that they don’t know what theuser wants. Also, project success criteria maydictate that schedules and functionality aremore important to the success of a develop-ment effort than operability (i.e., human fac-tors issues). To reverse that argument,operability (work) issues must be made visibleto the development manager early in projectdevelopment.

SuccessesBefore there was a desktopconcept or vision, workpractice observations hadalready been initiated. Theseobservations informed ourexecutive management andencouraged discussion oftraining time, processingefficiency, error correction,and quality of work. Puttingwork practice at center stagefrom the beginning of thedevelopment effort madeoperability and usabilitycharacteristics key successcriteria for the interface.

Multiple opportunitiesto observe users and refinethe observation and inter-viewing process were avail-able because of the large

number of client sites. Clients were alwayseager to have us visit to see how their opera-tions were unique. We found that iteratingbetween analysis and observation cycles pro-vided a learning opportunity to refine theteam’s data gathering skills. During the earlygroup analysis sessions, I found that analystswere good at answering “how” and “what”questions but not always “why” questions(e.g., “Why did the operator open a batchqueue before processing the transaction?”).Knowing the answer to the “why” questionallows designers to support the user’s workstrategy. Our BAs needed to learn that lesson;cycling between observation and analysishelped. It seems easier to appreciate the bene-

As in any development effort, time con-straints are intrinsic. We often sacrificed for-mal work practice modeling anddocumentation. As a group, we used white-boards to quickly iterate and evolve our workmodels into high-level storyboards. The story-board screen flows encompassed both theworkflow decisions and the window designs.We then erased the whiteboards. All furtheriteration was done using the storyboard screenflows. We regret that sacrifice. As other teamsjoin in the continued development of ourdesktop, they are forced to learn the workflowstructure by examiningscreen flow structure.Understanding the rationaleof why a design is presentedin a certain way is difficultto ascertain from the win-dow structure. As teammembers move on to otherprojects, the detailed work-flow knowledge they haveattained will be lost. To mit-igate the loss, we have initi-ated an oral history processto recapture the design ratio-nale. We are recording ourBAs talking about userworkflow and how it is real-ized in the user interactiondesign. We will organizethese recordings into ascripted presentation andshare it with new teams thatare adding functions to the desktop. We hopethat a historical perspective on user workflowand how it is incorporated into the design willassist new teams in maintaining the integrityof the user interface.

Change is difficult. The introduction offield research methods, explicit workflowdesign, and usability evaluation was new tothe DST development enterprise. Many timeswe were asked “What makes your project sodifferent?” Our answer was “the use of rapiddesign iteration and explicit methods tounderstand user needs.” Success on one pro-ject, however, does not automatically lead toacceptance of a methodology on other pro-jects. There are lots of reasons to resist change.

PERMISSION TO MAKE DIGITAL OR

HARD COPIES OF ALL OR PART OF THIS

WORK FOR PERSONAL OR CLASSROOM

USE IS GRANTED WITHOUT FEE

PROVIDED THAT COPIES ARE NOT

MADE OR DISTRIBUTED FOR PROFIT OR

COMMERCIAL ADVANTAGE AND THAT

COPIES BEAR THIS NOTICE AND THE

FULL CITATION ON THE FIRST PAGE.

TO COPY OTHERWISE, TO REPUBLISH,

TO POST ON SERVERS OR TO REDIS-

TRIBUTE TO LISTS, REQUIRES PRIOR

SPECIFIC PERMISSION AND/OR A FEE.

© ACM 1072-5220/99/0100 $5.00


We have initiated an

oral history process to

recapture the design

rationale.


a r t i c l e

methods to respond to them during theirnext project in software development. Thevalue of the entire process, from field obser-vation to work analysis to interaction designand evaluation, was demonstrated by theactions of the entire analysis and design team.Working and learning as a group allowed usto leverage our skills and develop a “trustedcoworker” atmosphere. Mentoring was animportant piece of our success because itencouraged delegation and ownership of theprocess. Rather than having one personresponsible for “usability,” the entire BA teamlearned how to appreciate and control theconsequences of their collective user-interfacedesign decisions.

AcknowledgmentsI would like to thank project leaders PaulLyons and Bridget Wagstaff for their collabo-ration and support throughout this project. Ithank Rick Guess, Suzanne Ryan, and MikeWilligan for contributing to the workflowdescriptions contained in this paper.

References1. Beyer, H., and Holtzblatt, K. Contextual Design:

Defining Customer-Centered Systems. Morgan Kaufmann

Publishers, Inc., San Francisco, CA, 1998.

2. Keil, M. and Carmel, E. Customer-Developer Links

in Software Development. Communications of the ACM

38. 5 (1995), 33–44.

3. Nielsen, J. Usability Engineering. AP Professional,

Chestnut Hill, MA, 1993.

4. Rudd, J., Stern, K., and Isensee, S. Low vs. High

Fidelity Prototyping Debate. interactions 3.1 (January

1996), 76–85.

All trademarks mentioned herein belong to theirrespective companies.

fits of knowing a user’s work strategy if youhave experience in applying the knowledgeduring design.

Demonstrations to our clients and potentialcustomers were invaluable sources of feedbackon our ideas and inevitably garnered feedbackabout our approach and methodology. Wefound that clients were delighted that we weretaking a customer-centered design approach.Once they understood that our methodologyplaced their operators at center stage and thatwe wanted to understand the efficiency andtraining roadblocks, they were eager to have usvisit their processing environments.

From the beginning, we had a small designteam with a variety of skills. Business, soft-ware, and human factors skills provided a vari-ety of perspectives. The small size was easier tomentor and easier to organize. As the develop-ment team grew, we kept a small, consistentcore design team and had additional rotatingmembers. Members joined or left as the sys-tem functions they were responsible forbecame relevant or were “finished.” The smallteam was generally aware of all windowdesigns and was an effective force for main-taining the integrity of the interface. Havingrotating memberships broadened the skillstraining beyond the core team and maintaineda high degree of historical knowledge.

Perhaps the part of this project with whichI am most pleased is the success of the men-toring process. I began with a BA team withno prior usability engineering experience andlimited development experience. Learning bydoing was a process that was emphasized bythe project management team. As a result, inaddition to the new desktop rollout at yearend, the company has a group of BAs that aresensitive to users’ needs and can apply various

instituting integrated workflow...

Documents