The Turn

“Every great magic trick consists of three parts or acts. The first part is called “The Pledge”. The magician shows you something ordinary: a deck of cards, a bird or a man. He shows you this object. Perhaps he asks you to inspect it to see if it is indeed real, unaltered, normal. But of course… it probably isn’t. The second act is called “The Turn”. The magician takes the ordinary something and makes it do something extraordinary. Now you’re looking for the secret… but you won’t find it, because of course you’re not really looking. You don’t really want to know. You want to be fooled. But you wouldn’t clap yet. Because making something disappear isn’t enough; you have to bring it back.” – Michael Caine as ‘Cutter’ in “The Prestige” (2006)

When I and many others leading the charge describe the Experience API, this year we talked about it in terms of problems it immediately solves given the state of standards in learning technology today: we enable tracking of learning experiences via mobile devices, native applications, games and simulations; we allow for the tracking of individuals and groups of people; we account for different roles and responsibilities in a given learning experience, such as facilitators or teachers as well as “learners.”

I couldn’t be happier that the greater community has embraced this with as much enthusiasm and momentum as we have today. 2012 has been an incredible year. This was our pledge — Experience API is something very much like you’ve seen before with SCORM, but it allows for more.

I’ve presented it like this over the last year because I’ve come to believe, very strongly, in something Jane Jacobs wrote many years ago in her seminal work, “The Death and Life of Great American Cities.” Jacobs wrote about new ideas.

“As for really new ideas of any kind – no matter how ultimately profitable or otherwise successful some of them might prove to be – there is no leeway for such chancy trial, error and experimentation in the high-overhead economy of new construction. Old ideas can sometimes use new buildings. New ideas must use old buildings.”

To introduce something as new as what Experience API portends for the greater Training & Learning Architecture now being realized, it had to be introduced in the context of what people in our community already know and understand. It has to enable all the things that one currently does with SCORM, lest it be rejected simply because it doesn’t do that which you already know, but better/easier/faster/more awesome.

So… this is where things now turn.

Like a magician, this is where I’m going to move the learning, education and training out of the picture for the moment and tell you that Experience API is really not about learning, training or education as you know it. Yes, it enables all those things you’re already doing. No, it’s not really about those things at all.

In this last year we’ve talked a little bit about the need for people to own their own data. There are many practical reasons for this. One reason is that for a lot of people 30ish years-old, the only way to move ahead in the workplace is to keep moving. Most people don’t have employment in one organization that will span their career. Most people entering the workplace will have many different jobs, even different careers, and they’ll be working well into a different kind of retirement as we think about it today.

There’s no need for people to own their data if they can’t learn from it or use it to inform, change and/or improve themselves. Among the few criticisms that have pointed to what we’re doing with the Experience API, there is one that itches at me. The field of Instructional Design, as it is practiced today, is prone to track everything with the Experience API, and the critical question asked is, “what good will come of that?”

I’ll tell you straight up: no good will come of tracking everything.

I think what people need for themselves, what managers and business leaders and teachers and leaders and coaches of every stripe want is useful information about performance. Performance is largely not about creating content at all; it’s about making meaning out of what people do and using that knowledge to help people do better.

Here’s an anecdote: Big networks like Google and Facebook track lots and lots of information about what we do online. When I talked to people who invest a lot of money in online campaigns that involve either, I’m told that neither organization can easily share much about even the demographics of the audiences that respond to the campaigns. Given how much data they have available, it surprised me.

My hypothesis is that large networks can track every interaction, and I think because they track do track so much, they know very little about who is doing what, in what context, towards a particular goal. By being first to make it easy to track everything, they have a mountain of data, but it’s like looking for a needle in a haystack without knowing what the needle looks like. Such data infrastructure is built for general purposes (and, um… to sell us stuff).

If we want to find useful information about performance — the kind of information that helps us learn about what we do as individuals and teams and, further, help us improve, we start with the tools and media people use in a given activity with an assumption of what’s people are supposed to do with them. We describe this in terms of what are the interactions in which one would participate, given the designed activity/activities. We then design an experience that captures specific information that supports that hypothesis of what’s supposed to happen.

This isn’t a one-and-done process… it has to spiral — it must be tweaked and iterated. As a designer and as an analyst, we’re interested in the truth: are our assumptions about what’s supposed to happen correct? If so, if we track some more things, will those also prove correct? If what we expect to happen doesn’t happen, what does that mean? Perhaps we need to look at other information; perhaps we need to design a different set of activities (or redesign the existing activities differently) to create the desired experience.

The breadcrumbs we create by doing this tell a particular story. It is up to us, before all the data is even collected, to define what it all should mean, in terms of some competency or goal. What we do then is more like matching a particular needle while the haystack of information builds — very different from what Facebook and Google do, and I think this is a very different approach from what higher-education does with learning analytics today.

This is how we need to think about the consulting practice of the learning professional, the educator and the trainer — the value we add to our organizations, be they schools, hospitals, small businesses, large businesses, militaries or governments.

The value of what we as professionals can do with the Experience API is going to be realized by others: the business analysts, the managers and the mentoring figures and coaches in our concerns. We’re harnessing this technology for them.

As professionals we tend to talk about the value we add to an organization in terms we’ve been conditioned to use: “how do we help people learn?” I hear the lamentations of instructional designers everywhere. For ten years, I’ve been part of this field of work, and the complaints about this have grown louder.

“They come to us with the courseware already decided as a solution.” Well, we as a field haven’t offered much else to change that presumption. Start doing something different, which is easy for me to write and very hard to do… the world is changing and we must change a bit with it, realizing our value by the contribution we make to a bigger, shared goal instead of our value being realized simply by the objects we make. Our jobs are to help people improve so that as organizations or communities, we improve. Building courseware is not our job; it’s a by-product.

“We don’t have a seat at the table.” Well, kick down the door to whatever meeting is going on and bring a business analyst with you, and show your C-level person what you can demonstrate about how people are doing their work that would make your company more money.

That is a conversation your business partners want to have.

Working hand-in-hand with your business analysts, your enterprise architects, your accounting department… working with these people capture relevant information about what happens before, during and after a customer encounter is but one tool you have in your arsenal that is really relevant to the organization.

Working as a multi-disciplinary team, you can still make use of the foundations of instructional design (even ADDIE), designing interactions that collect evidence of performance — helping the individuals, teams and organizations make informed decisions instead of designing/developing content not knowing how it’s really helping.

My pledge to you was that Experience API would be able to do everything SCORM does, but better. That is still absolutely true. The turn is that doing this isn’t so much a benefit in and of itself — the benefit to the organization is different than you’ve been able to realize with the tools most of us use today.

You’re not going to cheer for this yet because you’re cheering will happen when learning comes back to the front again — real, honest-to-goodness learning (and it will — believe me).

Make no mistake, though — this is where the ordinary service you’ve provided to your organization can become something vital and extraordinary. It’s not going to be a turn-key solution — not for a long time.

It’s going to be the hardest thing our communities have ever done, but we have an economy to rebuild and a whole bunch of people we can enable to develop themselves. If we’re to be relevant at all, we need to be working toward much bigger goals. The information will come from data we design; exchanged and expressed with the help of the Experience API.

We’re going to make it happen.

Original post