Performance-Centered Design Implementing Performance-Centered Design News & Views Feature Article

by Craig Marion, Senior Member, Philadelphia Metro Chapter Originally published in News & Views May, 1997 issue. Copyright 1997 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.

This is the second of two articles presenting basic concepts of PCD. The first article, What Is PCD and What Can It Do for You?, can be found in the March 1997 issue of News & Views. Software that is performance-centered is created from the outside-in--from the perspective of the workers who use it--rather than from the inside out--to reflect data structures and system functionality. It’s designed for ease of learning and use rather than just to offer features and perform functions. While PCD as championed by Gloria Gery was developed with and from her work on electronic performance support systems (EPSS), PCD also rests on decades of research and theory on usability engineering. Implementing PCD involves many usability techniques. If they are already in place in your organization, building on them would be a sensible way to advance your PCD efforts. A readable and well-documented overview of the field is Nielsen’s Usability Engineering (1993). For a quick glimpse of many of the techniques, see www.best.com/~jthom/usability/. Nielsen gives his own suggestions for beginners at www.useit.com/papers/guerrilla_hci.html. A panorama of the programs that seventeen leading companies use to ensure usability is presented in Wiklund (1994). If you’re not already familiar with usability labs, see also www.microsoft.com/usability/tour/default.htm, but be aware that many important usability activities precede lab testing, and that a formal lab is not necessary for testing (Tognazzini 1992, p. 79).

How you implement PCD will depend on the current structure of your organization, the staff and skill sets you have available, and your other resources. Unless you’re working in a start-up or an organization undergoing complete reengineering, chances are that you’ll need to build PCD activities into an existing development cycle. You’ll need to promote and sell the concept, form strategic alliances with advocates of related agendas in your organization (such as usability engineering, software engineering, or the Capability Maturity Model), and eventually win the support of senior management.

If you’re working in a small organization and want to try PCD on your own, a useful guidebook is Bauersfeld’s Software by Design (1994). A complementary volume is Tognazzini’s Tog on Design (1992). Both of these approaches come from the Apple/Mac culture, and the results achieved there commend them. If you’re working within a larger organization, obtaining the services of a consultant who has already implemented PCD will increase both your credibility and your effectiveness.

Most of the activities you need to build into your software development cycle take place in the first "half"--during the requirements, definition, and design phases--before coding begins. These activities will and should elongate this half. Some of this time will be made up in the coding and testing phases--where detailed design information will quicken coding and reduce both bugs and the need for retesting. Additional measurable time and costs will be saved by your customers after the software is delivered.

As early as possible . . .
Identify the User Interface (UI) Team. The team should include users (both novice and expert), a subject matter expert (SME), the product planner, a software engineer who understands data structures and the technical side of any previous iterations, a developer who will be doing or overseeing the coding and can express any limitations of the platform, and a technical communicator. Additional participants might contribute graphic design, human factors, computer/human interaction, and/or cognitive psychological expertise. Ideally, a user interface designer should lead this team and the team should be independent, and not under the authority, of the development organization.

During the requirements phase . . .
Traditional software requirement gathering focuses on features and functions required by user groups. Its task modeling focuses on identifying the tasks users need to complete, the functional requirements of these tasks, and how data needs to be organized to support the functional requirements.

PCD recognizes that this is insufficient. It devotes more time to understanding performer classes and the contexts surrounding tasks. It captures the performers’ language, mental models, and goals as well as their activities, and it studies workflows to simplify and optimize them rather than just to replicate them.

A well-established methodology for richer requirement gathering is Contextual Inquiry (CI). The principle behind CI is that there’s no better way to learn about work than to watch people do what they do where they do it and talk to them about it. Through CI, teams visit workers on location and perceive and articulate environmental and motivational factors as well as the work itself. CI’s principal creator is Dr. Karen Holtzblatt, who recommends the introduction in Holtzblatt and Jones (1993). Introductory information is also available at http://www.incent.com/, the website of Holtzblatt’s and Hugh Beyer’s consultancy, incontext enterprises. See especially www.incent.com/Digest.html.

It’s important that both the UI team and the development organization be involved in these early activities. The articulation of performers’ goals and mental models must be shared throughout the project team.

During the definition phase . . .
This is the phase in which the product’s scope is determined. Platforms, data structures, and data flows are analyzed. Product objectives are established, and a functional spec and a high level technical spec delineating components and their interaction are created.

UI modeling, based on detailed task modeling from the previous phase, begins here. The UI designer should lead this effort using the techniques and methodologies of his or her choice. If you have no qualified UI designer, the team may want to begin with a straightforward approach developed by Dayton, McFarland, and Kramer (1997). A brief capsule of it entitled "Participatory GUI Design from Task Models" is available at www.acm.org/sigchi/chi97/proceedings/tutorial/Dayton/td_txt.htm. A similar perspective is given in the "Design of the System" section of www.incent.com/papers.indx/Customer_Des_teams.html.

Beginning in this phase and throughout the coding phase, the UI is tested iteratively with representative and actual performers. This is done before any coding takes place through techniques such as storyboarding and paper prototyping. See Chapter 4 in both Bauersfeld (1994) and Nielsen (1993).

Also during this phase, a determination is made as to what can be accomplished in the UI and what supplemental devices--such as agents and guides--must be coded. Optimally, these add-ons are integrated into the interface. This involves attention to UI logic, which "orchestrates the relationship among and between the UI and underlying system code and extrinsic support resources." (Gery 1995, p. 75)

Performance requirements, sometimes called usability goals or usability specifications, are also established. They’re easier to set for new versions than new systems because benchmarks exist. For new systems, this step may not be possible until a later phase. But the step is important: without performance requirements, iterative design has no end-point. (Hix and Hartson 1993, p. 222)

During the design phase . . .
This is the phase in which detailed product specifications are established. The UI is clarified in detail and communicated to the development team. Iteration and communication are key elements here. Progress is made in stages. Vertical (partial features, full functionality) and horizontal (full featured but limited functionality) prototypes are developed. Carefully designed scenarios provide important performer feedback from small development efforts. (Nielsen 1993, p. 99 ff.)

Other usability engineering activities continue and usability lab testing begins. Rubin (1994) is a good cookbook.

Detailed technical specs are then created. Documentation, training, and testing are planned.

Continue your iterations through the code and test phases
Coding and testing (including additional usability lab testing) then proceed. You may want to regard "performance" as the final phase in your development cycle, beyond delivery. If you do, continue your usability studies at the customer site and establish benchmarks for future releases. (Nielsen 1993, p. 71) You may also want to capture metrics to establish customer savings in training and implementation costs.

What opportunities does PCD present for technical communicators?
Many technical communicators have been user advocates for years. Creating WinHelp has brought many of us closer to development teams. Find out where and how the developments sketched in this article are making inroads in your company and get involved with these teams.

New roles are forming: usability engineer, user interface designer, EPSS specialist, and the like. Each requires expertise and experience, but moving into these roles is every bit as realistic for technical communicators as it is for other information professionals. Explore the Internet: follow what the key players are doing in their consulting groups and universities all over the world. If you’re looking for a place to start, check out www.chesco.com/~cmarion.

Remember the words of Woody Allen: "The only thing standing between me and greatness is me." That goes for all of us.

References

Bauersfeld, P. 1994. Software by Design: Creating People Friendly Software. New York: M&T Books.

Cooper, A. 1995. About Face: The Essentials of User Interface Design. Foster City, CA: IDG Books.

Dayton, T., McFarland, A., and Kramer, J. 1997. Bridging User Needs to OO GUI Prototype Via Task Object Design, in User Interface Design: Bridging the Gap From Requirements to Design, ed. L. Wood and R. Zeno. Boca Raton, FL: CRC Press.

Gery, G. 1995. Performance Support: Performance-Centered Design. Copyrighted by Gery Associates, Tolland, MA. (413-258-4693)

Hix, D. & Hartson, H. 1993. Developing User Interfaces: Ensuring Usability Through Product and Process. NY: John Wiley.

Holtzblatt, K. and Jones, S. 1993. Contextual Inquiry: A Participatory Technique for System Design, in Participatory Design: Principles and Practice, ed. A. Namioka and D. Schuler. Hillsdale, NJ: Lawrence Earlbaum.

Rubin, J., 1994. Handbook of Usability Testing. New York: John Wiley.

Tognazzini, B. 1992. Tog on Interface. Reading, MA: Addison Wesley.

Wiklund, M. 1994. Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: AP PROFESSIONAL.

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 16, 1997 (rst)