News & Views Performance-Centered Design
What Is PCD and What Can It Do for You?
News & Views Feature Article


by Craig Marion, Senior Member, Philadelphia Metro Chapter

Originally published in News & Views March, 1997 issue.

Copyright 1997 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.


This is the first of two articles presenting basic concepts of PCD. The second article, Implementing Performance-Centered Design, can be found in the May 1997 issue of News & Views.

In the software development world -- particularly in companies that have been around for awhile and created their niche using mainframes and minis -- once a software product takes its place in the market, it tends to be enhanced regularly with additional features and functions that its users request. Over the years, it does more and becomes more complex.

Many of the resulting products have become harder to use. And now, as many of them are being recast in client/server environments, a number of critics are raising red flags. The world of workstations is very different from the world of dumb terminals. It offers many new opportunities and its audiences have very different expectations. Providing lots of features and functionality will not in itself make products in this world successful. Ease of use matters, too -- more than many companies that create this software realize.

The origins of Performance-Centered Design
About ten years ago I was a Microsoft Word (for DOS) enthusiast. When version 4.0 came out, I became convinced that it had become a better word processor than the market leader, WordPerfect. I wrote an article explaining why and sent it around to the popular PC magazines. Personal Computing liked it, recast it as "Point/Counterpoint: Word vs. WordPerfect," and published it in the May, 1988 issue.

My essential argument was that while WordPerfect did indeed have more features and functions than Word, Word did the most important things better. Or as I put it then:

A word processor is not simply the sum of its features. While many complex features are used rarely or not at all, it is the basics that determine user satisfaction. And it's precisely in its basics that Word has legitimately surpassed WordPerfect. (1988, p. 128)

I then went on to illustrate such things as how, in WordPerfect, it took six keystrokes to block and move text, while in Word it took three.

As these things happen (Jung calls it synchronicity), other software users were having similar thoughts. One such person -- Gloria Gery -- was exploring much larger vistas than I was. Gery had already established a wide circle of influence from her advocacy of computer-based training (CBT). She was at this time both widening her view of what information could be delivered electronically and focusing on how this information could be made more useful to workers. In mid-1989 she was working with a group from AT&T on the concept of "knowledge support systems" and envisioning tools that could be added to workstations to give workers just enough information, precisely when they needed it, to enable them to do their work more easily and quickly. The term "electronic performance support systems" emerged from this project to describe integrated suites of these tools. (Gery, 1991, p i.)

Gery brought this perspective to a number of other projects and presented the results in the book Electronic Performance Support Systems (1991), which is generally regarded as the seminal work in the field. Take a look at the number of consultants who now create these systems (visit www.epss.com or www.tgx.com/enhance) or the conferences devoted to them (www.cts.com/~ngraves/ps96 or www.ondaweb.com/inter96). EPSS is now a movement.

While staying in touch with the evolution of both CBT and EPSS, in the past few years Gery has once again refocused. This time she has trained her attention on the basics. Gery's red flag is a herald that, from a design standpoint, hard-to-use software is ipso facto obsolete. Why? Because we now know how to create easy-to-use software that does the same things in ways that enable its users to get their work done faster and better. Gery calls the path to creating easy-to-use software Performance-Centered Design (PCD).

PCD is not meant to replace EPSS. It's rather a focus on foundations. If the interface is optimized, it will require fewer add-ons. And as EPSS elements become more integrated with the interface, the lines between the two will probably blur.

For those of you not yet familiar with these developments, take heed: as more software industry insiders grasp the thrust of PCD, it could become a movement, too.

What is Performance Centered Design?
PCD infuses tools with knowledge, structures tasks, and enables performers to achieve the required level of performance as quickly as possible -- at the very most, within a day -- with minimum support from other people.

Software that is designed around performance is intuitive to its users and enables them to perform their normal work with obvious gains in speed and efficiency without ever attending training classes or looking things up in books. It reflects their own conceptualization of their work and incorporates their language, idioms, metaphors, and understanding of how to perform tasks.

Intuit's Quicken is a good example. Virtually every user approaching the program and seeing a blank check on the screen knows intuitively what information needs to be input and where it goes. The same with the ledger, and with reconciliation. The program builds on knowledge its users already have.

Another way of grasping this central point is to consider how software is constructed. Wilson and Bramer of Andersen Consulting explain it like this:

Traditional transaction-based systems are designed with an emphasis on process and data modeling. In a way, they are designed inside-out. The user interface modeling is derived from the process and data structures. For example, the layout of screens is often a reflection of a record structure, and the menus of the system reflect the functional structure.
Performance systems are more interactive, and more oriented toward actual work circumstances. Thus, these systems need to be designed from the outside-in. The character of process and data modeling in itself does not change so much, but the (outside) user interface modeling drives the (internal) process modeling and data modeling.
In simpler terms, begin with what your workers are doing, with what you want them to do, and what support they need to be successful. Everything else about the system flows from that basic orientation. (1994, p. 62f.)

 Or, as Gery puts it, "When designers have the point of the view of the performer situated in a real work context, success is inevitable. If the point of view does not closely match the situation, usability and performance problems are inevitable." (1995b, p. 31)

Why "performance" centered?
PCD is about human performance, not system performance. In fact, PCD is about shifting the attention of software designers away from systems.

Why not "User-Centered Design"? Again, Wilson and Bramer answer clearly:

One of the enduring truths of this technological age is that when organizations begin by speaking primarily in terms of systems, they will inevitably end up thinking of their workers primarily as systems users. System users are oriented, not toward the work they are performing, but rather toward the system on which they are working. (p. 46)
We don't want workers to be thought of as system "users"; that makes the system itself the dominant focus. The focus, again, should be performance-centered. We want to enable workers to do their jobs, not focus on having to use a system. (p. 37)

Development teams need to look beyond systems considerations to create software that optimally supports their users. The old paradigm held that if the system provided the functionality, it was up to the users to learn and use it. PCD rejects this. Workers are too busy to learn complex systems. They need to focus on their work. It's the system that has to come to them, not the other way around. Whatever they need must be apparent and at their fingertips, while they’re working.

Concepts/terminology
Gery organizes the support that workers can obtain online into three types.
Intrinsic support is inherent to the interface. It's so well integrated that, to the user, it's part of the system. There's no thought of being supported. The user is just doing normal work. The wizards that guide you through establishing accounts in Quicken are an example. They're overlays that provide structure to the software, but they're presented to the performers as normal work in the context of the system.
Extrinsic support is integrated with the system, but the user breaks the task flow to obtain it. Finding out how to do something using online help is a common example.
External support requires the user to break the work context entirely. Stopping work, finding a book, and looking something up is one example. Attending a training session or calling a help desk are two others. (Gery, 1995a, p. 51f)

In 1995, Gery asserted that most systems provided perhaps 20% intrinsic support. The rest was extrinsic and external. The goal of PCD is to stand this on its head. In a well-designed PCD system, 80% of the support will be intrinsic: integrated with the interface and workflow. Only 20% will be extrinsic or external. (1995b, p. 39)

Many of the other PCD concepts, such as layering information and hypertext links, are familiar to most technical communicators. So are the terms granularity (creating modules such as CBT elements that are targeted at simple, specific tasks), agents and guides (such as Microsoft’s wizards and cue cards). A number of artificial intelligence (AI) terms are also commonly used.

One recurring concept of basic importance is that knowledge needs to be embedded in the interface. A worker needs to be able to look at the interface and understand exactly what needs to be done.

In traditional work environments, knowledge about task performance, work context, concepts, consequences, and so on resides almost exclusively in the job holder’s head. Such knowledge and logic must be developed prior to using software and the performer must be inherently competent at calling relevant knowledge to the fore and structuring task progression. Performers must know what must be done, how to do it, and all knowledge related to that task. . . . In performance-centered systems, knowledge related to both system utilization and work performance are incorporated in the underlying system logic, the interface itself, and within all support resources. (Gery, 1995a, p. 64)

What does performance-centered software look like and how does it behave?

Many innovations are the result of individual or team creativity and iterative design employing rapid prototyping coupled with ongoing usability and performance testing. Articulation and communication of these emerging design structures and principles will be necessary to achieve wide-scale and rapid development of new and powerful software systems that accelerate individual and organizational performance." (Gery, 1995a, p. 48)

To this end, in a paper entitled "Attributes and Behaviors of Performance Centered Systems" (1995), Gery has examined popular software and extrapolated a list of nineteen attributes that many well-designed interfaces employ. She cautions that it’s not necessary that all software employ all of the attributes. But when they’re applicable, they’re pertinent.

Gloria Gery's 19 attributes of performance centered software
The first group focuses on setting a context, clarifying what you’re going to do, and then doing it in the best way:

  1. Establish and maintain a work context.
  2. Aid goal establishment.
  3. Structure work process and progression through tasks and logic.
  4. Institutionalize business strategy and best approach.
The next, on what appears on the display:
  1. Contain embedded knowledge in the interface, support resources, and system logic.
  2. Use metaphors, language, and direct manipulation of variables to capitalize on prior learning and physical reality.
  3. Reflect natural work situations.
  4. Provide alternative views of the application interface and resources.
The next, on system-user interaction:
  1. Observe and advise.
  2. Show evidence of work progression.
  3. Provide contextual feedback.
  4. Provide support resources without breaking the task context.
The next, on system behavior:
  1. Provide layers to accommodate performer diversity.
  2. Provide access to underlying logic.
  3. Automate tasks.
  4. Provide alternative knowledge search and navigation mechanisms.
  5. Allow customization.
  6. Provide obvious options, next steps, and resources.
And finally, the one that’s already practiced. Gery puts it last because while it’s necessary and important, it’s far from sufficient.
  1. Employ consistent use of visual conventions, language, visual positioning, navigation, and other system behavior.

In this paper, Gery examines five consumer software products that she regards as particularly well designed from a performance perspective. She illustrates each and explains how it employs the attributes. One of them, Microsoft Publisher (version 2.0), "incorporates most, if not all, of the attributes of Performance-Centered Design." (p. 65). The splash window that greets workers upon entering Publisher is shown in Figure 2 along with the attributes that are illustrated.

Gery's text and 24 illustrations serve as a virtual gallery of PCD. The Center for Educational Technology at Florida State University has put the issue of the journal that contains this paper online at www.cet.fsu.edu/sy2000/PIQ /PIQContents.html. Students at the College of Education at the University of Missouri have subsequently analyzed additional software products in terms of these nineteen attributes (tiger.coe.missouri.edu/~perfsppt).

At just about the same time Gery published this paper I began to notice another interesting movement in the direction of PCD. I was capping off a certificate in instructional design with a course in CBT. As my class presentation, I decided to compare the tutorials provided by Word for Windows 2 and the next iteration, Word 6. I noted that in Word 2, the CBT was modularized. You picked a topic that explained several logically-grouped functions and were informed on the first screen that the module, complete with a quiz, would take, say, seven minutes. In Word 6, the CBT had become granularized. You picked the specific function you wanted to use from an "Examples and Demos" section and were shown how to do precisely that -- no more and no less. You didn’t have to wade through related functions (or take a quiz). And it took seconds, not minutes.

Word 7 dropped "Examples and Demos." This information is now part of the help system. You pick what you want to do and Word gives you the steps or does it for you. (The principles employed, updated for Office 97, are presented in a Microsoft white paper at http://www.microsoft.com/office/office97/documents/intelsns/default.htm.) Both help (documentation) and granularized CBT (training) have been integrated into the product.

What’s the business case for doing it?
Companies such as American Express Financial Advisors have achieved dramatic improvements by employing PCD. They reduced their training time by 85% and their error rate by 90% simultaneously. In another situation, a hotel chain documents that it previously took new employees two weeks to learn 80 percent of front-desk procedures. A performance-centered interface reduced training time by 93 percent and guest checkout time from 40 to 80 percent. (Raybould, 1996)

But isn’t PCD expensive, and won’t implementing it threaten software delivery dates? Gery is firm in her retorts:

It's interesting to me that people think intrinsic support will always cost more. I assume every system will have an interface. To make that interface obvious is no more expensive than making it arcane, obscure, data driven or from the wrong frame of reference. It's just done by different people. (1996)
It could be viewed (as more expensive), particularly by IS people, because they are unaware of or have denied all the costs associated with systems implementation. For example, some will complain of the more extended activity in iterative interface design . . . In fact it does take longer, but not when one considers that virtually all training, documentation and help desk activity is compensatory for interfaces that don't achieve that. (1995b, p. 72)

A project's target dates should be expressed as "when performance is achieved by employees" and not "when the software arrives." (Reybould, 1996)

If PCD is such a good idea, why isn't it being done more widely?
Most software companies, as many of us are reminded daily, are not Microsoft. The way work has been done in the past is still being automated with limited imagination. Development organizations scurry to create bug-free code on time and on cost. Documentation, training, and help desks compensate for deficiencies. All this has become institutionalized, with the inevitable vested interests, silos, and tunnel vision.

PCD is a quantum leap concept that has inevitability on its side. It’s pointing to the emerging face of the software of the future and clarifying what this software looks like, how it behaves, and how it’s created. Of course, the more brilliant and useful the software of the future turns out to be, the more ridiculous the stuff we produce today looks. But how else could it be? The computer revolution is just emerging from toddlerhood.

Think big picture. The basic challenge facing our society on the work front is enabling service workers and knowledge workers to be more productive. Software that will enable workers to meet new performance goals -- and the companies that provide it -- will succeed. And not all software, and companies, will.

What are the implications of all this for technical communicators?
Job responsibilities are going to change and blur. From the perspective of PCD, much of the work currently done in documentation departments is explaining poor design. As PCD progresses and systems become easier to use, the need to explain complexities is going to diminish.

All this won’t happen overnight, of course. And opportunities to make other contributions to new and better products are increasing in ways that many writers will find liberating. Some of them will be explained in the continuation of this article, Implementing Performance Centered Design, in the May issue.

References

Gery, G. 1996. Nov. 15 reply to Cost of intrinsic and extrinsic performance support. Forum at www.epss.com.

Gery, G., 1995a. Attributes and Behaviors of Performance Centered Systems. Performance Improvement Quarterly, 8/1, pp. 47-93.

Gery, G., 1995b. Performance Support: Performance Centered Design. Copyrighted by Gery Associates, Tolland, MA.

Gery, G., 1991. Electronic Performance Support Systems. Cambridge, MA: Ziff Communications.

Marion, C. & Pepper, J., 1988. Point/Counterpoint: Word Versus WordPerfect. Personal Computing, 12/5, p. 127-134.

Microsoft Publisher. Microsoft Corporation. One Microsoft Way, Redmond CA 98052

Raybould, B., 1996. Tech Talk: Performance-Centered Design. Training & Development, March 1996, p 72.

Winslow, C. & Bramer, W., 1994. FutureWork: Putting Knowledge to Work in the Knowledge Economy. NY: The Free Press.

Craig Marion is an independent consultant who includes PCD among his specialities. Both parts of this article are available at www.chesco.com/~cmarion/PCD/ImplementingPCD.html. You can email Craig at cmarion@chesco.com.

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Last updated: May 18, 1997 (rst)