At DevLearn this year, I gave a session on Advances in Robotics and How They Apply to Learning. I reviewed the participant feedback on the session and although mostly positive there was one main piece of feedback that I got that I feel I could follow up on in this medium. Other pieces of feedback are equally helpful but more for me to incorporate into future presentations. By the way, shame on those who feel that the session was a waste of their time and failed to stand up and walk out. In any case, that one piece of feedback was that folks wanted practical examples of how to apply what I spoke about.
Here are a few things I think we can apply within our sphere of control as instructional designers. First a recap of the main points:
1) Change our problem statement from how do we train somebody to do a job to how do we help someone adapt to their environment.
2) Allow the performer to be the interface
3) Engage the body
4) What can we build to make people superhuman
5) Apply distributed networking principles
6) Don’t digitize the analog world, merge analog with digital
Its important to realize that all of these things work together at different times and will affect design in different ways, in different contexts. But lets get very practical. First off, I’ll tackle number 1. The difference between training somebody and giving them the tools to adapt to their environment can easily be seen in how we typically train employees on new software. We create simulations, animations, pages with information, tip boxes and some of us use robohelp to insert instructions directly in the software. All of these things are great as long as software doesn’t change. But all of them require rebuilds everytime it does and only robohelp doesn’t require somebody to leave the software itself if they need help. All of these things have chunked content in a way that groups entire processes together and gives everybody exactly the same information in the same way.
Easy alternatives to this type of training are:
1) Use virtualization technology that generates ‘images’ of software that people can play with using ‘guides’. As the software changes so will the virtual instance. The ‘guides’ should be written less as step by step, but more about try to accomplish ‘x’ in the system and here are signs that your moving in the right direction. Allow employees to access external resources for help
2) Something like Robohelp is good, but create a more robust search within the software that allows a search outside the software. Allow external resources to be generated by employees and create a web of resources based on employee contributions to knowledge pool. Employee contributions can be screen shots, movie grabs, wiki contributions, etc.
3) Send out challenges to employees asking who can get to ‘x’ in ‘y#’ of steps? This will engage employees in building their own efficiencies and allow postings to be part of external resources.
The impetus here is to trade a little bit of getting it ‘right’ the first time to building competence and allowing people to improve and adapt based on a collective pool of resources to which they are a part of.
What about #2, allow the performer to be the interface. In the world of motorcycling, I used a BMW to explain how the industrial engineers are building feedback loops into the vehicles themselves that get their feeds from the rider and feedback to the motorcycle, which in effect feeds back to the rider. So a rider starts by telling the motorcycle, I am inexperienced and I am riding in rain. The motorcycle starts to carefully monitor wheel slippage and lean angles to make sure the rider isn’t giving too much or too little gas for slippery pavement at a specific lean angle. The motorcycle, instead of cutting throttle power, will only give the rider the ability to go to a certain amount of throttle. As the bike gains confidence in the rider the rider is given more leeway and becomes a better rider as a result. So there is this marvellous system in place that allows for personal development between man and machine.
In practical terms, lets take selling insurance, and training sales people to sell insurance policies. Our programs tend to break down in actual selling skills (listening, body language, art of persuasion, etc) and information on the policies themselves. One way to build a feedback loop into this is to provide a way for sales people to log sales (ideally in the CRM of the company itself) in a way that allows them to see where they succeed and where they don’t. Allow a sales person to understand and see contextual patterns in their sales and provide the means for them to improve in specific contexts. Example: a sales person might be great on the phone but horrible in person. And what type of people are they horrible with? Casual, formal? What type of industry? Associate information with different contexts and allow the sales person to dig in and improve. Can anybody say xAPI?
Moving onto What Can we Build to Make People Superhuman?
So I love to tell the story of how a Ricoh sales person sold us a copier for our office. The process took 3-4 weeks from the time he met us to the time we said ok. Why? Well, we had questions. Technical questions, process related questions, product questions, etc. Whenever we had a question that he could not answer on the spot, it took a couple of days to get back to us which took us a couple of days to process, compare and get back to him with more questions. Its easy to see that giving a sales person access to tools that can help answer questions on the spot and prepare materials for his customer on the spot would make him superhuman. My new venture SlideJar does this for presentations. It allows content to be searched and accessed outside of their original presentation based context. If I need an answer to one question, don’t provide me with a book, just give me what I need to get over this obstacle.
So time as it were has run out on me. Hope this has been helpful and hopefully folks that were at my DevLearn session get to read this.