Jay Cross has an eloquent post talking about the history of Performance Support, ending of course calling for considering the learnscape. Tony Karrer comments on it in his own post looking at performance support and learning technology.
Interestingly, what Jay doesn’t really cover in his history is that Gloria came up with Performance Support to cover up bad interface design. The systems were monolithic and essentially impermeable to change, so she wrapped a solution around it. The interaction design field was a little put out about the whole performance support system notion, saying it was really just good interface design. And there’s still too little of that, sad to say (I used to teach interaction design, and it’s a component of the performance ecosystem solution).
What Jay points out, however, is that the learning designer needs to take responsibility for more than just courses, and it’s ok if information is the solution (“‘Information is not instruction.’ …if information gets the job done, it doesn‘t matter whether it‘s instruction”).
However, Jay starts lumping all of the web 2.0 tools into performance support, which is where Tony gets curious. He thinks some of the tools fall more into the knowledge management category, but admits he may be getting definitional. He is in agreement about the need to look at the larger picture and consider all these tools as playing a role in meeting ePerformance, a term he and I agree upon.
Jay cites Marc Rosenberg, and Marc certainly has been calling for us to include knowledge management, performance support, and eCommunity as part of our tools to go beyond eLearning. Which is where we’re all in agreement. Good reading, good thoughts, good work.
Jay Cross says
Thanks for picking up on this, Clark. I guess I need to consider enlisting a proofreader. Or a meaning-reader. You write that I didn’t cover the fact that Gloria came up with Performance Support to cover up bad interface design. Doesn’t this say that?
“Thirty years ago, expedient mainframe programmers upgraded applications by slapping overlays atop original code rather than rewriting the user interface. Users had to jump back and forth between three or four screens to complete a transaction. No matter that applications were clunky and inefficient; that could be covered up with a training program. Gloria Gery, a training manager at Aetna manager, saw the folly in this approach. Why should people have to learn something that could be designed into the system in the first place? Why not provide them with information when they needed it?”
Clark says
Jay, sorry, I guess I took it as she took a different approach: instead of training around, or fixing the interface design, she slapped another layer on that provided help. Which is what she could do, but it wasn’t fixing it. And I’m happy to be wrong; you’re closer to her than I was.
Dave Ferguson says
As Gloria and many others know from painful experience, “training” is often the Clearasil smeared on the zits of bad system design.
I think the quote about instruction is dead on. People who see themselves as “trainers” get caught up in training, and end up missing both the performance-support and the performance-improvement boat.