Granting Three Wishes through Performance-Centered Design
by Gloria Gery

The genie appeared when the monitor was rubbed. "I’ll grant you three wishes, Ms. Manager. What will they be?"

The manager thought hard and decided, "Why not go for broke and ask for my real software fantasies: Wish #1: I wish I could just bring people onto the job, sit them down and have them start being productive on day one. Wish #2: I wish I didn’t have to staff with one person to support three people answering questions about the work itself or helping people use related software. Wish #3: I wish anyone could perform as an expert so best practice is a way of life here, rather than the occasional ‘star’ performance.

Genie: That’s it? Nothing difficult? Those can be granted with a simple twist.

Manager: A twist? I don’t get it. These things don’t seem to be simple at all. I keep asking for these outcomes, but we don’t seem to understand what it takes to do it. We have user-interface standards that require Windows compliance. We even do usability testing. But we still have huge learning curves, support costs and frustrated users. What’s your twist? I don’t want to hear of another innovative catch phrase… I want something practical, affordable and high impact.

Genie: The twist is to change a few simple things:

• Your goals for the system
• Your assumptions about the users
• Who is involved in the design process and when they are involved
• Usability test participants

If you do what I command, you’ll have your wishes without any magic at all, much to my dismay. And it won’t cost you more than a traditional software design – and will cost a lot less than the traditional implementation because much of the cost of training and support will be eliminated. As a matter of fact, a more powerful benefit will occur: time to performance will be virtually immediate and all of the hoped-for benefits of the system will be achieved.

Manager: Too good to be true – but tell me more – I could use a laugh.

Genie: O.K. Let’s set some context and look at the drivers and assumptions around corporate software. So many of these assumptions are implicit and anchored in history that most people specifying systems requirements and those developing them don't even discuss them – never mind question them. These assumptions need to be revisited given the new kinds of work we are supporting with software, and the new design possibilities that visual and task-focused systems offer.

A Powerful Data-Oriented Heritage

In the 1970s when the infrastructure, methodologies, specifications, architecture and goals for large-scale corporate systems were set, the focus of applications software was data processing. The hardware was, of course primitive by today’s standards. But hardware aside, the first 10 to 15 years of application development were focused on structuring environments to capture, transform, and report on data – largely transaction data. The first systems I remember were insurance, banking, and accounting systems – and the user- interface models were the data entry forms that people used to keypunch from when batch systems were the rage. OF course, since the paper forms couldn’t be represented well and since display screen real estate was such a priority, these "data entry" screens contained huge numbers of fields with minimalist cryptic labels. Since people weren’t doing anything but entering data that existed on source paper forms, the focus was on rapid data entry. And since data transmission was costly, the goal was to have as much on a display as possible before pressing Transmit or Enter. The work was repetitive – with little or no interpretation by those interacting with the systems. Once they learned the screen names and memorized the field labels, they could work quickly. Crowding fields onto the display and minimizing the number of screens, transmissions, and data edits were the goals. Storage drove a tradition of Error Messages, which came back as numbers. In my old days as an insurance data entry clerk, we had manuals on the shelf with thousands of error codes. We went to the manual to get the code and figure it our. People's time was cheaper than machine capacity. Ah, the good old days! Unfortunately, developers and designers are still operating on old, now invalid assumptions. And accountabilities are still around the old goals: bug-free code, accurate data transformation and on-time, on-budget delivery. These are all important – but they aren’t sufficient in a performance-focused, time-urgent, high-standards world.

Manager: Hello! Where are you going with this and what does it have to do with my software fantasies?

Genie: Stay with me. Understanding the historical drivers has everything to do with understanding why today’s software isn’t delivering on its performance promises.

Setting the Development and Design Defaults

What this original context drove was responsibility for user interface design in the IS department whose goals were data capture, transformation and reporting, and machine performance. Even when machine capacity increased, the mental models for most interface design, the methodologies associated with requirements analysis, design and development focused on data. The 3270 terminal, green screen character display became the design default. Just yesterday I was looking at a spanking new system that was done on a huge workstation in a client server environment – and the display was Windows-compliant. But when you stripped away the fact that people could select field values from list boxes rather than enter them from memory – and modal dialogs appeared so the displays were less crowded, the focus of the interface was on data. There was little or no task support. When asked for my opinion I said, "It looks like a pretty 3270 display to me!" Of course, the folks weren’t too happy with my comments, bur that’s all right. They can’t hurt me! Actually, I told them I thought I was in a Dilbert cartoon Frame. Not a cool thing to say.

Analysts See Only Data

The developers conducted their analysis of system requirements. They asked all kinds of questions about the system use, what people would be doing. They even had the luxury of going into the field and seeing some work observations. A real rarity, even today. But when I was secretly hovering over their shoulders, I noticed that they seemed to Focus only on the data requirements associated with the task. When people talked about what they had to think about when gathering the data in discussions with customers, no one explored char further. No one asked about how the work presents itself. And few discussions occurred about tasks – except to discuss in what sequence the data was needed to accomplish those tasks.

Who Is Consulted

Interestingly, only experts in the work were consulted. Most of the experts actually were not workers, but staff business experts from various departments like marketing. When the actual workers were consulted, only long-term employees were included. No novices were consulted. They were dismissed as not knowing enough co be helpful. Of course, I think they are expert at a very important thing: not knowing anything about the work. So those folks are "expert at being novices" – but when I planted that seed, I was told that my concerns were a training issue, not a systems design issue.

Manager: Net this out, please....

A Big Difference from Consumer Products

Let’s do a quick comparison with consumer products that are now so popular. Products like Turbo Tax (Intuit Software, Tucson, Ariz.), ManagePro (Avantos Performance Systems, Emeryville, Calif.) and greeting-card, label-making and ocher systems are very different. People sit down and just start working. There’s no training and, when support is required, it's hardly ever about how to do something. The difference between consumer products and corporate software is huge and growing. And it shouldn’t be.

Manager: But our integrated manufacturing systems and call-center systems are so much more complex than these trivial consumer products. You're wasting my time.

Genie: Not at all! Yes, your applications are more complex Functionally and data-wise, but the interfaces and integrated performance support should be as seductive, compelling and powerful as the consumer products.

Chart Those Differences

As you requested, I’ve netted out the differences in what drives consumer vs. corporate software and presented my results in the table "What Drives Software Development.'" It’s in understanding the subtleties of assumption and motivation that you can see requirements changing. IF you assume people know neither the work nor the software, you’ll be more explicit, more visual, more metaphorical, more structured than if you assume otherwise.

Manager: Interesting. We just have been asked to give our customers direct access to our system co have them answer their own queries, perform their own order entry and changes and do other tasks. We’ve been trying to figure out how we would be able to train these folks who are far and wide and not subject to our control. You’re suggesting if we assume no training will be available, we'll have co restructure the interface to reflect that assumption. We’d probably be less cryptic, embed more knowledge, give better feedback and provide greater clarity about consequences of actions. I suppose we should have been doing that all along, but we always assumed users would know the work and training would be a precondition of utilization.

More Criteria Please

This idea is appealing, but I’m afraid we don't know how to specify such requirements – and we wouldn’t be sure we had achieved it. Can you help us out here with some guidance from your magical abilities? (Maybe if I were to rub the monitor again...?)

Genie: No magic at all. As a matter of fact, you do have lots of models in the consumer marketplace. You simply must look beyond the specific tasks to glean the lessons. I have bought every piece of software I could find and combed through it all to describe and classify the attributes and behaviors of these popular performance-centered systems that are selling by word of mouth because they are powerful and require short or no learning curves. I’ve also been reading the various business magazines for stories about how and why these products become so successful.

The Attributes and Behaviors of Performance-Centered Systems

There are some very specific things that must be incorporated into software to generate immediate performance by all. It’s critical to be able to describe and demonstrate these attributes and behaviors in order to build the requirements into functional specifications and to provide explicit models for design. In addition, these characteristics also serve as evaluation criteria to be able to observe and articulate additional design requirements or point our design limitations.

There are at least 26 attributes – too many to describe here, but point your Web browser to www.epss.com/lb/lb_index.htm. The more of these attributes that are incorporated into the application (and the better the implementation of the attribute), the more powerful and performance-centered the system is. In fact, these characteristics go well beyond the traditional definitions of user-centered design – but certainly a focus on the users and their characteristics is a very important part of this approach. Performance-centered design encompasses the user focus as well as a focus on context, process, task, knowledge and data representation. In addition, there is a priority to achieve high levels of integration of knowledge, task structuring support, data, and tools.

Manager: This could be overwhelming if I tried to swallow it whole. But when it’s broken down, it seems more manageable. The software descriptors like:

• Establishes and maintains a work context
• Aids in goal establishment
• Structures work process
• Structures progression through tasks and logic
• Contains embedded and accessible integrated knowledge, and
• Institutionalize best practice

These phrases all seem so much more concrete than words like usable, user-centered or friendly. They also are more helpful than saying things like, "We’ll use wizards."

Genie: Good. And when you add on factors such as:

• Use natural language that reflects the workplace and customers
• Visualize using metaphors
• Provide alternative views of the application interface and/or data
• Provide evidence of task progression and so on, It gers increasingly clear.

I suggest you visit epss.com and look at some of the online articles to get more examples and elaboration on these points. There actually is a community out there consciously developing the systems that define the new com-puter-mediated workspaces. You’ll connect to many resources there. There’s a good interactive forum there as well.

Training, Documentation, and Support: Compensation for Bad Design

Also, since performance-centered design integrates activities that are now occurring independently and sequentially, such as training and documentation – it’s important to understand that those who understand the technology and data are not likely to understand the work, human cognition, knowledge representation and learning. Workers in other organizational units need to be involved early and have direct influence over the interface. Since most training, documentation and support are compensatory for bad interface and support resource design, these folks have learned a thing or two about what works and what doesn't.

Usability Test Participants and Testing for Performance

Manager: Earlier you mentioned something about who should be involved in the iterative design and usability.testing. Fill in the blanks, please!

Genie: But of course! This is a subject for much longer discussion, but the bottom line is that in addition to having expert performers test the system, it becomes increasingly important to bring novices into the evaluation process very early. Experts have so much tacit knowledge of the tasks thar they are often able to compensate for the interface without realizing it.

Manager: But won’t expert performers be frustrated!

Genie: There will be some discussion about whether the interface and support required for novices won't "slow experts down." It's my experience, however, that if the task representation is right and there are alternative methods available, that the question isn’t whether there’s an expert or novice mode, but which mode the performer prefers to work in. For example, in Turbo Tax, users can work in either the Interview or Forms mode. Depending on prior knowledge or experience, confidence, consequences of error or task complexity people can work entirely in one mode or toggle back and forth between modes. I know I’m very confident about filling my name and social security number on the tax form, and I can do some other basic things. It’s when I get to those depreciation schedules that I become so concerned about messing up that I prefer the highly structured interview mode with available knowledge linked to the situation to explain things to me.

Another example is with the popular Quicken program by Intuit. There’s no expert mode. Because the checkbook is such a powerful metaphor, folks just decide to work in either the Register or Check mode. When the representation is right, there’s no mode based on knowledge.

Manager: I’m sure we could go on, but this is quite enough to begin. Thanks for the frame of reference adjustment. I needed that. I’ll need to discuss this with my IS professionals, bring in the training and documentation people and see if we can’t get a dialog going. It seems to me that while this might generate additional requirements, the benefits in implementation reduction, increased utilization of the systems, and overall business benefits would make this worthwhile.

Genie: The benefits are enormous and link to far more than efficiency and effectiveness. The real power is being able to institutionalize best practice and integrate strategy into software. The added value is tremendous. And sponsors just love it. They want more and more once they see this stuff.

Manager: Thanks a lot.

Genie: Before you leave, would you rub that monitor one more time?

Table 1. What Drives Software Development?

A Comparison of Large-Scale and Consumer Software Development

Further Reading

Books:

Gery, G.J. Electronic Performance Support Systems. Gery Performance Press, Tolland, Mass. (Previously published by Ziff Institute and Weingarten Publications, 1991).

Norman, D. Things That blake Us Smart: Defending Human Attributes in the Age of the Machine. Addison-Wesley, Reading, Mass., 1993.

Tufte, E.R. Envisioning Information. Graphics Press, Cheshire, CT, 1987.

Journals:

Dyson, E. Performance Support: Worker information systems. Release 1.0, August 1993. EDventure Holdings, New York, NY.

Galagan, P. Think performance. Training and Development Journal (Mar. 1994).

Gery, G.J. Attributes and behavior of performance centered systems. Performance Improvement Quarterly 8, 1 (1995). Also accessible from www.epss.com.

Gery, G.J. Training vs. performance support:

Inadequate training is now insufficient. Performance Improvement Quarterly, 3 (1989). International Society for Performance Improvement, Washington, DC.

Raybould, B. Performance support engineering: An emerging development methodology for enabling organizational learning. Performance Improvement Quarterly 8, 1 (1995). Also accessible from www.epss.com.

Sherry, L. and Wilson, B. Supporting human performance across disciplines: A converging of roles and tools. Performance Improvement Quarterly 9, 4. Also accessible from www.epss.com.

Web Sites:

epss.com site: www.epss.com

EPSS infosite: www.tgx.corn/enhance

CBT Solutions site: www.cbtsolutions.com