Digital Performance Support — Great idea, 25 years in the making!

It’s been over 25 years since Gloria Gery, Barry Raybould and others defined the concept of Electronic Performance Support Systems (EPSS). Their broad vision was compelling but, at the time, there was no realistic technology to enable that vision.

Over the last 25 years, incremental progress has been made one puzzle piece at a time involving different technologies and approaches. To put this in perspective, let’s revisit Gery’s original definition for EPSS from her book “Electronic Performance Support Systems: how and why to remake the workplace through the strategic application of technology” (Weingarten Publications, Inc., 1991).

“EPSS is an integrated electronic environment that is available to and easily accessible by each employee and is structured to provide immediate, individualized on-line access to the full range of information, software, guidance, advice and assistance, data, images, tools, and assessment and monitoring systems to permit job performance with minimal support and intervention by others.”

That was a mouthful then and it still is now.

To date, no one has been able deliver on that grand vision. There is no fully integrated platform enabling employees at their moment of need with a digital delivery of resources to help them competently perform all aspects of their jobs. However, there is a broad range of technologies that are getting incrementally closer.

I threw this graphic together a couple of years ago for a talk to a Learning & Development audience. It’s a bit of a “Maslow Hierarchy” of learning and knowledge transfer methods for application users. The number of tool/technology providers that get involved with these methods is extensive. The bottom line, there was not then and there is not now a technology that does it all. Technology selection must be a function of many factors including the nature of your workforce, the performance outcomes desired, the level of IT support required, your budget and the ability to gather the talent necessary to use the technologies effectively. In other words, it’s all about selecting the right tools for the right purposes.

Since the mid-2000’s, the concept of EPSS has narrowed from the broad definition proposed by Gery and others to what was technically feasible at the time, namely, context-sensitive help for software. Oracle and SAP led the way with tools that created help content for their software which was made available to users from within the software. These types of tools gradually improved, adding features, getting easier to use, generating more outputs, adding the ability to manage the content and the ability to be used on other software. One of the top requirements of these tools was the ability to create and manage a lot of content because the “big bad” software that were the early adopters were complex, usually with hundreds of transaction types and often well beyond. These tools enabled the automatic documentation of a whole software transaction or process and automatically generated various reference materials (a.k.a. performance support content) made available to software users on-demand as they worked in the “big bad” software. I refer to this class of EPSS as Process Level EPSS.

Starting around 2012, a new type of EPSS emerged that embraced the concept of Micro-Learning. At first, these tools, all SaaS, provided in-application help at the field level in the form of dialog boxes with instruction for that specific field. This was soon expanded to include “walk-throughs” which push a user from one field to the next, providing instruction as they go. I refer to this class of EPSS as Field Level EPSS.

Actually, the terms Electronic Performance Support and EPSS have been fading away. One by one, the new tools have been categorizing themselves as Digital Performance Support which is felt to better represent the focus on applications. So, from here on, I’ll use Digital Performance Support (DPS) rather than EPSS.

DPS is a great concept. In the B2C world, it’s very difficult, if not impossible, to train your users and even the best UI/UX cannot prevent all user error and frustration which can lead to undesired outcomes. Why not give your users DPS to guide them along at their moment of need? In the B2B world, it’s well accepted that training is expensive, disruptive and largely ineffective. Why not give employees DPS to help them at their actual moment of need anytime they need it?

Field Level DPS is great … in the right situation. Process Level DPS is also great … in the right situation. Unfortunately, there isn’t one DPS that is great for all situations. It’s still about the right tool for the right situation so let me suggest some considerations.

Generally speaking, Field Level DPS fits with applications with relatively low transaction volume (<20 processes) and the average transaction complexity is low (~10 steps). These parameters can rise to a moderate level (20–50 transactions and 10–20 steps on average) but because content creation is a productivity challenge for Field Level DPS, you’ll need to plan for a higher level of effort, time and cost to create and maintain the content. Content creation is a strength of Process Level DPS making it best suited for applications with higher transaction volume and complexity as well as situations where you intend to apply DPS to a number of applications in your enterprise, making content creation productivity important.

Currently, most Process Level DPS are not true SaaS, while all the Field Level DPS are SaaS. Also with Process Level DPS, most will say they are web-based but the nature of Process Level content creation usually requires a desktop component for authoring. This can cause problems for deployment because IT will have to get involved.

Lastly, because Field Level DPS providers are all true SaaS, this makes this approach more affordable and easier to set-up for smaller employers (<100 users) and ISV’s of simple applications. For larger employers and ISV’s of complex applications, Process Level DPS is the best option due to the overall complexity of these situations.

Speaking in generalities is not always helpful but I believe these generalities will help you understand your need and help you ask questions to better understand which approach is best for you. Below is a summary of the considerations you should know about your situation as you begin to explore your DPS options. Of course, then you’ll have to pick the right vendor but armed with these considerations, you’ll be headed in the right direction.

1. Target Applications: How many could there be over time? Are any of these desktop-based and if so, for how much longer?

2. Process Volume: What is the transaction volume for your Target Application(s)?

a. Low (<20 transactions/processes/workflows)
b. Moderate (20–50)
c. High (>50)

3. Application Complexity: For your Target application(s), how many transactions fall into the complexity levels below?

a. Low (<10 steps)
b. Moderate (10–20)
c. High (>20)

4. Change Frequency: What is the frequency of change to the application(s) or transactions/processes/workflows?

5. IT Support: Will IT provide support in deploying your DPS?

6. User Count: How many users for your Target Application(s)?

If you want to learn more, please contact us today or schedule a demo. We’re here to help.