The Implications of EPSS for Technical Communicators

What Is the EPSS Movement

and What Does It Mean to Information Designers?

by Craig Marion

Performance support is anything that helps workers perform tasks. In software industry, three types of performance support have become institutionalized: training, documentation, and help desks. These three institutions arose because so much software is so difficult to use. It requires lots of training, documentation, and phone calls to specialists.

A movement that's acquired the awkward name of Electronic Performance Support System(s) (EPSS) has developed a vision of the next stage of software development that challenges this software and these institutions. EPSSs are sets of tools that effectively automate training, documentation, and phone support, integrate this automation into applications, and provide support that's faster, cheaper, and more effective than the traditional methods. EPSS proponents argue that training is forgotten, documentation is ignored, and help desks are unnecessarily expensive. Develop an EPSS instead, they encourage, and the whole organization profits.

In this article -- in addition to explaining what EPSSs are and pointing out where you can learn more about them – I'd like to clarify a challenge that the EPSS movement poses to the field of technical communications in general and to the specialization of information design in particular. In situations where the scenarios I allude to in the Conclusion take place, our individual responses to this challenge may have a bearing on both our jobs and our job prospects.

Learn More from the Web

The easiest and least expensive way to learn more about EPSS is on the web. Several overviews are available. The quickest introduction I know of is a PowerPoint presentation by Barry Raybould, an early advocate who is now focusing on the connections between EPSS and knowledge management. For those who prefer a more linear approach, Chet Leighton's "What is an EPSS?" is nicely done. More recent is Elke Remmer's "Guidelines for WWW-Based Support Environments for Education Professionals". It both discusses EPSSs and deals with extending them onto the web. If you're interested in still greater depth, the most comprehensive treatment I'm aware of is Dr. Pamela Northrup's distance education course on EPSS Design.

Certain web sites are devoted to EPSS. The largest is epss.com!, but my favorite is a parallel site developed by Bill Miller called the EPSS Infosite. Look especially at the bibliography and the forum (an ongoing discussion group) within epss.com! and take the time to explore the Infosite in depth.

In 1991, Gloria Gery published ten analyses of EPSSs in her seminal portrait of the field, Electronic Performance Support Systems. Since then, a number of similar analyses have been put online. Bill Miller's "An EPSS Interface Design" is a good illustration, and epss.com! has a page with other case studies.

Another way to understand EPPSs is to explore demos of actual systems. Usability Sciences Corporation provides an online demo, and PTS Learning Systems a downloadable one.

A fifth avenue is through the major conferences that feature EPSS, Performance Support and Learning Technology. If you can attend future conferences, wonderful. If you can't, it's still enormously informative to study the programs. They provide a panorama of both the main themes and the main players.

Deconstructing EPSSs

As you can see from these various sources, EPSSs are integrated suites of tools aimed at enabling first-time users to perform proficiently with little or no training or help from others. The same software enables more experienced users to deal proficiently with new situations -- such as responding to support phone calls about matters with which they have no familiarity.

How is this magic performed? By clarifying and simplifying tasks, creating interfaces that are clear and obvious, and providing various support tools and granularized information -- often in redundant formats to suit varying learning styles and preferences. Key phrases that recur in an EPSS context are "just in time," "just enough," and "at point of need." And it's all integrated into an interface that reflects workers' own understanding of their work and the language they're accustomed to using.

There's no consensus on what the components of an EPSS are. An early and often cited deconstruction (Carr, 1992) presented four basic components of an EPSS:

An "advisor" to provide advice via expert systems and knowledge-based systems
An "assistant" to provide tools and on-line help
A "librarian" to make available reference and information databases
A "teacher" to provide Computer-Based Training (CBT).

A great deal has changed, of course, over a decade. The development of Microsoft's IntelliSense technologies has put "advisors" and "assistants" into the realm of mainstream development. "Librarian" functions are now gateways to web, and discussions of how to organize and present information effectively are hot topics among web designers. The "teacher" aspect is being transformed, too. Witness how Microsoft has included less CBT in every iteration of its Office products. And consider how advances in technology are making multimedia increasingly common.

At this end of the decade, there seems to be no consensus on the components of an EPSS. A focus on the concept by a mainline computer journal last year presented a number of differing examples (CACM, 1997). Yet there remains an element of commonality in the various approaches. To this end, I find the model presented by Bill Miller instructive. In his article, "EPSS: Expanding the Perspective", Bill describes an EPSS as software that improves performance by

Reducing the complexity or number of steps required to perform a task (process simplification)
Providing the performance information an employee needs to perform a task, and/or
Providing a decision support system that enables an employee to identify the action that is appropriate for a particular set of conditions.

The Model I Use

I find it useful to consider the elements of an EPSS in a manner similar to Bill Miller's. We might say that an EPSS has three dimensions. The first is the base software interface. The second is a layer of add-ons that enables users to perform more complex tasks -- that cannot be represented intuitively in the base interface -- quickly and easily. And the third is a parallel layer of add-ons that organizes work (domain) knowledge and best practices, modularizes them appropriately, and integrates them with the performance of tasks. I think it's useful to label these three dimensions

Performance-Centered Design
Performance Support
Knowledge Support

Performance-Centered Design (PCD) focuses on the base user interface and its optimization. It's concerned with such things as visual design, idiom and metaphor, having the software be task-oriented, using appropriate windows and window components, and having the software's conceptual model (the face it displays to users) be as intuitive as possible. I've written explanations of what PCD means and how to implement it. Laura Arlov's GUI Design for Dummies (1997) is a remarkably readable, informative introduction to the techniques involved.

Performance Support is scaffolding on top of the base user interface that helps workers use the software. Online help qualifies, but in the context of EPSS the term generally refers to more automated assistance. Microsoft's wizards and Show Me help are good examples. Wizards structure a path through a task by giving users clear choices on successive panels. Show Me help doesn't list steps; it demonstrates tasks. It walks you through making menu selections, brings up windows and dialog boxes, and illustrates appropriate choices.

Performance support assistance in completing software tasks sometimes, but not always, enables workers to get their essential work done. Consider the work of a clerk using software to check a guest into or out of a hotel. If performance support assistance is provided, it guides the clerk through the use of the software and completion of the work at the same time, because the two are coextensive. But consider the task of writing a letter. Assistance on how to do formatting would be performance support. But what if a company decides that its workers need assistance on what to put into the letter? This is beyond the realm of using the software tool -- of performance support -- and calls for something more.

Knowledge Support is that something more. Knowledge Support deals with assistance in performing knowledge-based work. It incorporates domain knowledge. Ideally, it's integrated with both the base interface and performance support. TurboTax provides a good example. On its Help display, a tab called Program Help provides performance support. Other tabs, beginning with Tax Help, provide knowledge support.

EPSS strives to make knowledge support more automated -- and interactive -- too. Popular vehicles are expert systems and decision support systems. Multimedia, such as video explanation clips that come with the deluxe editions of Quicken and TurboTax, and developments using the web present many opportunities for knowledge support.

The Challenge to Information Design

Not too long ago it was acceptable to put explanations of how to use software into books. Then the bar was raised. We needed to put this information on the product – into online help systems. And many of us are doing that now, and using creativity and innovation to make these systems easier to use and more interactive with products. We're turning online help into vehicles for both performance support and knowledge support. But many of us use help facilities (such as WinHelp) that put this information in windows that need to be summoned and overlay the user interface. And those of us wading into the waters of HTML-based help have no clear models of what's expected.

We're at a juncture now where the bar is about to be raised again. Gloria Gery's classification of three types of information support illuminates how (Figure 1). It used to be enough to organize information within books -- external to the work flow. Then we modularized this information, hyperlinked it, made it visual and interactive, and built online help systems. This made it more quickly accessible. But it's still largely extrinsic: it has to be sought outside the normal work flow, and many users don't seek it.

Figure 1: Gloria Gery organizes the support that workers can obtain online into three types (1995, p. 51f.).

Intrinsic support is inherent to the interface. It's so well integrated that, to workers, it's part of the system. When information is embedded in an interface, the way it is in wizards, and no action needs to be taken to access it other than the necessary steps needed to complete the task, this information qualifies as intrinsic support.
Extrinsic support is available within the system, but the user must break the task flow to obtain it. Summoning online help is the most common example. In 1995 Gery wrote that about 80% of the assistance offered to users in software was extrinsic and only 20% was intrinsic, but that these proportions could be reversed with better design.
External support requires the user to break the work context entirely. Having to stop work to look something up in a book, attending training session, or making a call to a help desk are all examples. EPSS is about minimizing external support and maximizing intrinsic support.

According to Gloria's typology, the challenge now is to make the information we deal with intrinsic to the work flow. The problem is, we don't have models for this. The book model, whatever its virtues, places information external to the work flow. The WinHelp model gives us an easy way to make information extrinsic, but doesn't help us much beyond this. Both of these models -- however well organized, formatted, chunked, and hyperlinked -- are document-centric. They regard information as something that needs to be sought. A challenge that EPSS raises for information design is: what are the models for treating information as something that needs to be revealed, at point of need, within the work flow?

Embedding Help into the Interface

One thoughtful analysis that addresses this challenge directly has been made by online help expert Cheryl Lockett Zubak. In her article "Design Models for Embedded Help" (IE 4+ version, other browsers and non-JavaScript users) she explains that "embedded help is user assistance that is part of the real estate and functioning of the user interface of a software application, rather than a separate application that floats (often to our dismay) above, and sometimes behind, a software application." She goes on to classify five approaches to embedding help into user interfaces:

Stationary embedded help is designed as a visible part of the user interface. It can be either part of windows and dialog boxes or comprise them entirely. Bill Miller's Interactive Guide illustrates the latter (Figure 2).

Figure 2: Bill Miller's Interactive Guide illustrates stationary embedded help.
Process embedded help is driven by tasks and processes in the application. The help changes as users proceed through a task. Process embedded help can be used to guide users through tasks, as in wizards or cue cards, or to clarify actions as users perform tasks. Bill's Interactive Guide (Figure 3) illustrates process embedded help, too, in a text-centric way. Other approaches to process embedded help use graphics (often cleverly and to great advantage).

Figure 3: Because making a selection in the application changes the help on the left, Bill Miller's Interactive Guide also illustrates process embedded help.
Instructional embedded help teaches and guides. It often provides domain knowledge as knowledge support. Instructional embedded help can lead to additional details on a topic, or a tutorial. Or it can guide users to where they need to be in an application and open appropriate windows. A coach that a team I worked with in early 1998 provides a good example. It accompanies workers through a product and provides both performance and knowledge support (Figure 4). It also tracks user accomplishments for administrators.

Figure 4: Plan Assistant, a coach developed by Strohl Systems, illustrates context embedded help. On September 29 this product was awarded third place at Performance Support 98's EPSS Design Contest. A more detailed portrait of the entire product appears on epss.com! along with other contest design winners. Plan Assistant © Strohl Systems 1998. Reproduced with permission.
Context embedded help interprets user actions, ascertains goals, and volunteers assistance before users request it. It takes into account what the user has done, what the user is currently doing, and which software objects are open at the moment. Microsoft's Office Assistant is the best known model (Figure 5).

Figure 5: Microsoft's Office Assistant pops up as the user is performing certain tasks and volunteers information. This example from Excel was displayed after Office Assistant appeared, asked if the user would like assistance on a selected task, and the user said yes.
Agent embedded help acts on the user's behalf. It does things such as inform users of software patches they haven't installed and retrieve them, or find information on appropriate web sites. In her article, Cheri cites TalkBack from Full Circle Software as a high-end example. It gathers information abut software bugs and automatically forwards the reports.

Cheri points out that these models are not exclusive. The best systems draw on multiple types that support one another. And that working with embedded help will invariably bring help designers into closer contact with developers than ever before, setting the stage for even more innovation and teamwork.

Conclusion

In an influential paper entitled "Supporting Human Performance Across Disciplines: A Converging of Roles and Tools," Lorraine Sherry and Brent Wilson (1996) showed that documentation, training, and performance disciplines are converging on the same issues and offering similar solutions. An implication is that these disciplines are moving toward redundancy.

As this perception reaches the mainstream it will have organizational consequences. On the one hand, it will be used as a justification for cost (i.e., job) cutting. On the other, it will promote the breakdown of silos, engender new cooperation, and result in teams capable of creating better, more usable software.

What can we, as technical communicators, do to prepare ourselves? Mary Deaton, another online-help expert, seems to me to have a good answer. It appears in a discussion entitled "Stop writing Help and start creating integrated support systems" (available online when this was written, but no longer -- CM 7/99):

I want Help developers to become performance analysts. I want user assistance for any product, mass market or otherwise, to look and feel like part of the application and like each other.

I never again want to see an online piece of user assistance that is not intimately linked to every other piece of user assistance for that product. Let's stop fixating on one tool [i.e., Help – C.M 3/98) and fixate, instead, on what the people who use products need to succeed.

The point can be taken even further. As Cheri Zubak points out as she chronicles the development of embedded help, the distinction that currently exists between user assistance and applications is crumbling. Not only do the two often interact, but in an increasing number of situations the user assistance is the software itself. (The whole category of agent embedded help falls into this category.) And many of the most exciting dimensions of improving user assistance are coming as user assistance blends into software.

The challenge to information design, it seems to me, is to analyze and clarify these innovations from a variety of perspectives. In addition to Cheri's groundbreaking embedded help paradigm, how else might we catalog the integration of performance and knowledge support into user interfaces (to help us understand and advance their effectiveness)? What other typologies can we devise to elucidate the weaving of information into applications more intricately, interactively, and usefully than it's done today? How do we determine what works well and what doesn't? And what principles and guidelines can be extrapolated to assist those of us who create integrated user assistance?

That's the academic challenge. The practical one is more immediate. As the online world morphs onto the web, many of us are being asked to design and create integrated approaches to user assistance right now. To give us perspective, insight, and suggestions on the future of online help and user assistance, Cheri Zubak's Help Matters webzine(IE 4+ version, other browsers and non-JavaScript users) promises to be a helpful source. (Modified 7/99 - CM)

But remember. Information designers are not the only ones pursuing this grail. Areas of the training and performance improvement communities (not to mention cutting edge mainstream developers) are working towards very similar goals, and the EPSS movement is the most prominent spearhead of this perspective.

Which is to say, the EPSS movement has been scouting, forging, and articulating paths to better and more usable software for a decade. Those of us scrambling to devise effective, integrated user assistance might want to consider becoming better acquainted with both its legacy and its recent achievements.