AI and the modern learner, with Paul Healy

Paul Healy starts this interview by introducing Learning Pool and how they came to chatbots as an approach when they started to think about what a modern learner needs. They felt a modern learner didn’t need another platform, they needed to be able to access learning as part their workflow in other platforms. Chatbots are a perfect way to place learning inside of another platforms. A chatbot means that a learner can pull in what they need just by asking the chatbot a question. Learning Pool’s chatbot, Otto, then goes out to multiple sources, including the content in your LMS and intranet, to find the answers.

Download the how artificial intelligence is changing the way L&D is working eBook

To go along with the podcast series on AI and L&D, we have released an eBook with transcripts of all the interviews. The eBook also gives a brief explanation of what AI is and an overview of how it is being used in L&D.

In the eBook you will learn:

  • Some of the jargon behind the technologies e.g. what data scientists mean when they talk about ‘training a model’. 
  • How AI is being used in L&D today to gain insights and automate learning. 
  • Why you should be starting to look at using chatbots in your learning programs.
  • How you can get started with recommendation engines 

 

Subscribe using your favourite podcast player or RSS

Subscribe: Apple PodcastsSpotify | Amazon MusicAndroid | RSS

Useful links from the podcast

Transcript - AI and the modern learner, with Paul Healy

Robin: At Learning Pool, you've been doing some work with rethinking how you're meeting the needs of modern learners. What sparked that review of how you engage with learners?

Paul: Let me take you back, and tell you a story that's gone on for over a decade. If listeners are aware of us from say, four or five years ago, they would have seen a traditional online learning company that was active in the local government sector in the UK. In terms of its product offering, it was a very traditional full stack learning company: reselling the Totara LMS, offering libraries of content, offering our own authoring tool, working in Storyline, and then doing bespoke learning on top of that. Quite a successful company: 150 strong, growing at about 20% a year. Happy with where we were at, but then quite ambitious at the same time.

We had a look about two years ago, to plot a strategy to double in size over the following three years. First of all, that's going very well, which is great. But it has three elements to it. One is continued organic growth with a transition into a lot more private sector business. We're not 50/50 local government: central government on the one hand, and private on the other.

The second was acquisition. We've been through a number of acquisitions, the most recent one Scottish. We now have a Scottish office in Glasgow. Two years ago, we bought Mind Click in Nottingham, and we’re always on the lookout for other opportunities in that space as well.

The third option was innovation. I was brought in a year and a half ago to work with the chief executive in the role of Head of Innovation, to plot that three-year strategy. Then to look underneath that at the various elements, particularly on that innovation stream.

Adapting to the needs of the modern learner

Paul: What really stood out for us was a sense that the learning and development community had got out of step with the ‘modern learner’. There's a particular slide called The Modern Learner by Josh Bersin. If you aren't aware of it, you should look it up. It describes the scenario of the enterprise employee, their attitude to learning and their set towards learning. The outfall is that the modern learner is a distracted individual, an incidental learner. It's a fairly low priority for them to want to go to another platform and to take courses.

Then when you deep dive into that core structure, a lot of the building blocks of what would make an online learning course were entirely unfamiliar to the modern online technology user.

We were able to identify people in, for example, call centre environments, workers in retail environments, who wouldn't even necessarily have their own corporate login, never mind their own corporate device. We've seen use cases in the airline industry where again and again we're being asked by progressive learning and development professionals to give them back solutions that aren't built on LMSs and aren't built on core structures. So that was the impetus that took us down this innovation path.

It's certainly a journey. We're 15 months into it. There's another two years of development work to run. But it's been a fascinating first 15 months, a lot of learning. There's some product out in the market, which we can talk about as we continue.

Robin: I'm thinking about a conversation I had with an L&D person who was new to digital learning this week. They wanted that traditional ‘push-out’ compliance training, but they also really wanted the sense of working, and supporting work happening in the flow. They were out searching for a platform for it. But at the same time I was thinking, ‘I doubt that there's a single thing that meets all these needs of building learning into the workflow, but also meets your traditional organisational-driven learning outcomes.’

What do you think is the part, in terms of the current learning experience, that is so focused around LMSs often in organisations, that's really not meeting the need of the modern learner?

Paul: Well, there's always a need for LMSs, and there's always a need for courseware. At the highest level, the stock phrase is that learning management systems are good at the management system and they're poor at the learning. If we tear at that and deconstruct it, essentially LMSs tend to be another platform, another place that people have to go.

Simplify the learning experience – three key elements

Paul: If you think about your working day, you're living in one or two key online environments, and that's where you want to experience your learning. I think sometimes that the L&D community overcomplicates the learning challenges that they face.

If you try and distil that down, these are the key elements: one, we need to be timely so that you're giving people learning and knowledge when they need it. Two, that it's relevant, so you're giving them information that's particular to what they're doing. Three, that it's accurate. Certainly, you've got to put a lot of stock in being precise and getting it right. If you get those three base elements of being timely, relevant and accurate, you're starting to make a difference to people as they do their job.

That's one of the core challenges, I think. That once you step outside the compliance learning that any L&D department has to face, that you've gone through the courseware catalogues that are required to cover, say, an insurance risk or liability that an enterprise might have. But the next tier up from that is actually to give people knowledge and information that helps them to do their job better.

Committing to compliance and the key elements of learning

Paul: That's why you start to see those phrases like ‘learning at the point of need’, and ‘learning in the workflow’. What I'm saying is that it's not an either/or scenario; I think it's both. To be able to offer statutory requirements that are expected of you from management within an enterprise, but then to start thinking about how you deliver to those three timely, relevant, and accurate mandates, which is all about the journey that we've been on.

There's a secondary layer in that too. Once you hit that base three, you also want to be sure that you're into that world of ‘can you push learning at people?’ Because often they don't know what they don't know. Is it repeatable? Can you get them again and again? Is it testable? But those are secondary dimensions to those first three.

Robin: I think you're right, there are both. It's not either/or. You can't throw out those things that are sometimes needed from an organisational point of view with other types of solutions and approaches.

I can't imagine doing compliance-based training with a just-in-time approach. There are so many things that could go wrong with it, Paul.

You saw this need. You saw that lovely three-level need. What solutions and approaches is Learning Pool exploring to try to meet that need of the modern learner?

Innovate by going to where people are – not by creating new platforms

Paul: Well, let me say first a few things about what we're not doing. I think that the first rule we had was: what the world does not need is another platform. We saw the momentum within a lot of the LMS developer community to start to add social elements. There are various themes that run, and one of the themes was that people learn from each other.

That's patently true, but it didn't mean that the technology response was to put a social platform inside an LMS. I think that the thrust of that kind of ideology, if you like, is really an attempt to make the platform king again.

We felt that the core thing was to take learning to where people were. In that respect, we actually were quite developer-led from our CTO, Mark Lynch, who was a great believer in the Slack enterprise collaboration tool. We could see a wave of these coming along, with the likes of Facebook, Workplace, and Microsoft Teams. We could see many of our clients maybe not universally adopting it, but certainly within a department level or regional levels, actually starting to use it. So we started to ask, ‘How can you insert learning into that?’ That's where the chatbot arose.

We're trying to knit something up here from a whole range of components. You can see, if you look out at the industry, all sorts of believers in certain technology threads or streams and trying to do things individually with those. What we set out to be was an integrator. Like, could we define a component stack that you could pick and choose from, to build the solution that met your need?

Learning in hard-to-reach industries with no learning infrastructure

Paul: If I give you a use case example for that: retail, or another one very similar to it is in the fast food industry, where you've got people who are meant to be serving customers. They need to know things and they need to do training as well. Typically they have to learn on their own phones. Typically they don't have, as I say, a corporate login to the organisation, and no learning environment where they can go to experience any learning whatsoever. Maybe it's just a little store room or coffee dock at the back of the store or the back of the shop. That's an environment that just is not met by a conventional L&D community.

But if you can get those people to access very short, sharp bits of information, if you can push the knowledge, and repeatedly push it to them so that it gets reinforced and embedded. If you can allow them, where they need to know something, to search and look it up in a performance support kind of way without any sight of any of the technology underneath.

Because the modern learner – if you go back to that phrase again – is totally unaware when they use Facebook, or particularly if they use Google in that part of search, totally unaware of the infrastructure and architecture or framework behind, that’s making it all happen. I think the imperative now, you know, is to remove all of that scaffolding and let us see the building, and the beauty of the building that's behind.

Robin: You used the word stack there, Paul. It's actually in lots of other industries, marketing in particular. It's a really common word. Rather than saying, ‘We're getting a platform,’ people say, ‘We'll get a selection of platforms that will integrate together.’

I use the word ecosystem, to talk about learning ecosystems as a culture of learning by working. Also the technology base: that you actually need more than one thing that works together. Then possibly, if you're doing what you're talking about, of bringing learning experiences into a digital work platform, like Microsoft Teams or Slack, it's a very different value proposition for the learner.

Learning on pre-existing, active platforms

Robin: Essentially, you're doing the learning in the same space that they're working and collaborating with people naturally, rather than it being an extra thing.

Paul: Well, one of the things there – and we actually stumbled upon it more than anything to be honest, rather than saying we were insightful – is that we use the Adapt open learning framework. We've built our own cloud-based authoring tool on top of that, called Adapt Builder. There are two elements to the way that content gets structured. The first is that all the text that's contained within the course is stored in JSON files. The second is that each component block within the course has a unique identifier that can be reconstructed into a URL.

What that means is, if you've got a powerful document search tool, which we have in our choice of Elasticsearch and which we can talk about later, it can index a course, and it can return any search snippets in a Google-like way, and it can build a URL back to that.

Effectively, what that does for us is you can experience a course say, a health and safety course. Walk away from that course and get a tick box from the compliance side of things. As we all know, when you walk out of the door or you've done the two-hour course and you walk away, you remember very little of it until the moment where you actually need to use a specific piece of information.

Pull in and reuse learning resources to reinforce learning

Paul: What we've managed to do – as I say, almost by chance, but we're immensely impressed with the way it works – is you can then search that course from within Teams or Slack or Workplace or really any enterprise collab tool. You get a snippet back and a link that takes you deep diving back to that piece of information within the course.

Effectively, you're getting that Holy Grail of reuse, where you can consume the content as courseware, or you can search as performance support.

Robin: Yes. Essentially, someone can come to the chatbot and ask a question – rather than the chatbot having to be programmed with that, which some of the other people on the podcast have been talking about.

Essentially, your system searches back through all the paths of all the learning objects that are back in the ecosystem, for the organisation to pull that in.

Paul: Yes, that's exactly right. Our out-of-the-box offer is a chat and search. Let me quickly walk you down to that tech stack, and then we can pick at some of the stuff that's underneath. It has a chatbot at the top. It has Elasticsearch as the search tool down into your courses and documents. It has our server software acting as an infostore and user management. Then it has the Learning Locker LRS sitting underneath.

Even if you come to us and you just want a chatbot, you'll get provisioned with that whole stack, but you just don't get exposed to any of that technology underneath. But if you're an enterprise level, say, tinkerer or visionary, we will give you hands on to the full stack to actually play with.

That's the full stack offer. But if you're engaging with us at the thinnest level, what you're getting is a chatbot with search. I totally understand what you're saying there, because we spent probably the first four to six months of that journey writing intents. We use Dialogflow, the Google Dialogflow chatbot editor. It's an immensely powerful product. It probably could be improved with some kind of tighter organisational function at the top layer, but it's quite a powerful tool.

But what it does for a content team is create another maintenance headache. You're writing hundreds and sometimes thousands of intents. You have all sorts of contexts and variables and webhooks to deal with to insert that chatbot into relevant parts of, say, a business process workflow. Then when it comes to an issue or a maintenance thing, to have to pick through those is quite a challenge.

What we've found is that although we have a chatbot writing team in Nottingham, England, we've moved towards thinner level communications UX at the top, and a deeper commitment to search. A solution, if you look at us at the chatbot layer, would be: we've got all the light layer UX: ‘Hey. How are you? What do you do? Tell me a joke. I'm tired.’ All that sort of communications UX layer, to get the sense that you're actually in a conversation.

We are quite adept now at the Dialogflow intent writing. There are a number of ways to do that, but at its base layer it's an FAQ-like structure asking a question and anticipating all the various potential answers for that. Or we can drag you through a guided type of instructional design, but what you're doing is you're setting a confidence level in the chatbot editor, if they actually understand the question.

When that fails and the chatbot isn't convinced that it's got an answer, we'll take that and we'll drop it into search. Effectively, we were listening all the time. We're saying, ‘Do we have an answer at the UX layer to this question?’ If we don't, we say, ‘Right, take that into search,’ and we drop that down. Then we bring you back a set of snippets with links.

What's fantastic about the Elasticsearch tool is it's a federated search particularly directed at documents. So it will search collections of documents, Office 365, OpenOffice, PDFs, closed caption video for YouTube clips – wherever you point it at – and then in our particular instance, the Adapt courseware.

Blending learning and knowledge by unlocking access to both

Paul: I'm hesitant to call it unique, but the other advantage of this as an approach is that this spurious distinction between learning and knowledge is blended. What we find we've been able to do is to create a search tool into learning collections, and at the same time to be able to stand up all sorts of PDF documents and standard operating procedures and HR guidelines in the same content bins.

Robin: Paul, it's just a really elegant way of doing that as well. Constantly, people want that challenge to be solved, to bring learning and knowledge together. They quite often talk about putting them on the same platform or having the intranet system reach into a learning management system and do the sort of things you're talking about. But bringing them together, and tying them together in the chatbot with a simple text-based interface is an elegant solution and approach.

Paul: Well, it's certainly imaginative. What we find is when we get out to the market and talk to it, and when you do meet progressive L&D people out in the world, it inspires them to start thinking of new ways that they can use it.

We've been speaking to a construction company lately. Their issue is that there'll be maybe 1200 people in that organisation and they're constantly working on multiple sites throughout the world. They've got a whole range of disciplines, whether you're a project manager or you're a plumber or an electrician or whatever, and they never know where anybody is.

Learning as a driver of information to solve organisational headaches

Paul: That information is actually stored in their LMS, bizarrely. I think it's Workday that they use.

Their issue is: say you're looking for a site manager for a new build and you want to know who's coming available in the next couple of months. They're starting to see that as a knowledge application that could get blended. If they can get that information as a text document out of Workday and make it searchable by our learning tool and Elasticsearch search engine, all of a sudden they've got a new knowledge application that emanated from the L&D department.

So you start to see edge cases like that, where all of a sudden people stop thinking about learning in a siloed way and start to think about how it's really about information delivery.

Robin: It's a good example of performance-focused L&D as well, around the whole business problem. It's not actually a training problem, it's a knowledge problem – here, we can help in this particular way.

Paul: The major struggle that we see again and again is to find where things are. It's not about learning models or designs. It's like, where is everything? Even when companies do start to use the LMS as a storage bucket for documents and presentations and PDFs and what have you. It's like they’ve become repositories rather than retrieval vehicles. They build up in there and nobody has any idea what's actually in the system.

Robin: Just to also make something really clear, and to explore and embed it into our conversation: why did you end up with chat as your interface, Paul, rather than a standard search?

Using chat to find and retrieve information

Paul: Yes, that's a very good question. I would have gone straight for search. Perhaps I think that we were beguiled by what was going on. I’m taking you back to early to mid last year. There was certainly a theme that was running in the industry that chatbots were the common thing. To an extent, that has waned.

But in fact, we've found a way through that to produce a solution that will still stand up. Because there is some utility to create that experience that you're actually chatting to somebody. I think that what was happening last year was you were seeing the Google Assistant and the Amazon Alexa really coming to the fore.

I think that's what was driving a lot of the idea that we'd soon be talking to our machines. There is some utility in that, but I think that we probably overreached. We were running very, very complex chatbot interactions. We were carried away by the marketing hype. We've settled back now into a much thinner UX layer. But it's still got good utility.

A lean chat interface as an effective interaction tool

Paul: Certainly, we could've simply provided a piece of JavaScript with a search snippet to put on an HTML page. Or to have written a browser extension that was branded as ours, so that you clicked that and it dropped down. But in a way it was probably too thin a solution.

In fact, if you take the chat in a box from us, our entry level thing, we will still give you that JavaScript search snippet to put on an HTML page if that's what you want to do. Because it's really a question of what's appropriate for you. That's in keeping with the component approach that we stressed. It's not ‘take what we've got’, it's ‘what do you need?’

Robin: If someone wanted to hunt out and know more about your chatbot system, Paul, where would be a good place to start?

Paul: Probably the website, I'd say. We call it Otto. So get on the website and look up Otto. At that stage, we have a demo of it working there, so you can see it on a mobile phone working within Slack. That's a good place to start.

If it inspires you and you can see a utility for it in your own organisation, then get in touch, and you'll probably end up with me giving you a demo. Some of the issues with it are that we're very used to per-user pricing in the LMS world. We'd be speaking to banks with 80, 90, 100,000 employees, and you create this terror if you suggest per-user pricing when they realise that they can open that up inside their intranet to perhaps 100,000 people.

I think that the learning that we took from that was, you'd be far better to take a lesson out of the cable companies and really go for an ‘all you can eat’ data approach with a fair use policy, or something akin to that. So that's exactly what we did.

Our entry level, what we give you is a secure FTP site to put documents into. We give you the snippet to put a pop-up on a webpage. We'll give you 50GB of data storage, and off you go. It comes with a standard set of Dialogflow intents, so you've got that first UX experience to get you going. Then we’ll set a limit: I think it's 150,000 searches a month, and really off you go. Knock yourself out. You can put that out to 200 people or 200,000 people as you like, and give you a chance to experiment, then to scale from there.

Robin: This relates to the myths of subscriptions and users. Essentially, for a tech company it's not what is the cost base, it's actually the amount of things that are used or storage space that's the cost space. So it's a different sort of model.

Paul: The true cost for us is in the API calls. You'll get the developers saying, ‘Well, this is what an API call costs and people roughly do these number of calls, and so let's get per-user pricing based on that.’ That doesn't work. It doesn't work to try and explain API calls to the market either. So that's where we hit on just go for all you can eat and fair use. There's no point in reinventing the wheel. The cable companies have got this done. They know how to explain this. So that's where we took our inspiration from.

Robin: Thank you, Paul, so much for joining me on this podcast today. It's been a bit more of a technical conversation, which I've really enjoyed. I wanted to actually possibly dive a little bit deeper, technically, a couple of times than what some of our listeners might want, but thank you. It's been fun. Great.

Paul: You're very welcome.