Adopting a New Approach to User Training

By Holly McDonald

Not so long ago, I attended a webinar on User Adoption which was for HR software vendors by William Tincup. I’m not an HR software vendor, so this wasn’t entirely applicable to me. But I do care about user adoption – except I hate the term.

User adoption is about helping new users become competent (or beyond) and comfortable with a system. Too often it’s just considered a “training” problem, but it’s really much more complex than that. It’s about behaviour change, and that’s never simple. It’s also often divorced from ongoing use. There’s the “go live” activity and it isn’t really tied to the ongoing. 

So, you may think running everyone through a three-day class on your new piece of software will get them up to speed, but how are you going to sustain that? What happens if they don’t use the software for a few weeks or months after the training? Will you have to hold refresher courses? Will you be beholden to the vendor to pay for ongoing training of your users? Of course, it depends on what kind of solution you are putting in.

When you are buying/building/implementing software in your organization, don’t think about just training, but approach it from a broader perspective. Think a combination of:

  • Good user-centered design – does this thing do what makes sense to the audience (not every software designed makes sense to the user) – when you are purchasing, get actual users to be part of the proposal review process. Sometimes there are assumptions that things work a certain way, when that’s not the case. 
  • Good user interface – does it make sense how to use it and access those things that you think it should do. Is it intuitive or are there 12 choices in a drop down menu? How’s the screen laid out? Do buttons for approve/reject seem logical…here’s a resource that you could use to help you put together your own assessment 
  • Change management – this is used in the IT/software world in a different way than OD pro’s would use it. In software implementations, it’s about getting people to want to use your system, so are you clear about the benefits to the end user? Are you describing these benefits and how so? Some people think extrinsic rewards are the way to go – you know the things that sit on your desk/at your cube reminding you how great the software is. I’d rather energy be spent on the first two things, so that it makes their job easier than the corporate swag, but that’s personal opinion, I have no evidence to back that up, just a hunch.
  • Communication – people need to hear things in a variety of ways before they actually get it. Between 3 – 7x has always been my rule, but make sure you are telling them what it actually means to them day-to-day. Clearly outlining what’s changing and what’s not changing or what will be different on day one is important. Don’t be surprised if you’ve said it, but “they” didn’t hear it. We often fall into the trap that we’ve told them so we’ve considered that successful communication.
  • Training – this is about them actually learning how to use the system (both in terms of what to put where and your business rules/policies/etc). Don’t spend weeks training them on the whole thing, instead pare it down to the top 3 – 5 things they’ll need for Go Live day, then share with them all the ways that you’ve built to support them. Don’t forget those stats that tell us we forget a lot of what we “learn” in a class. Dr. Will Thalheimer talks a lot about spaced repetition being really important in learning
  • Performance Support – I’m a big fan of Bob Mosher, he’s got an awesome book about performance support, or you can read old blog entries (which are pretty informative). Performance support is about after people have “been trained” and need a little help. A couple of tips: focus on where people might make mistakes, think about the things that they are not going to do frequently as places to offer “help”. Sometimes this is assumed to be online help, but unless it’s contextual sensitive and explains business rules, it’s not all of it. Don’t be afraid of a few paper items to help new users or to provide reminders of tasks that they are less familiar with.

It’s important that you think about day one – Go Live day – and identify what you want people to do with your new software on the first day. An analogy – “Go Live” is like the wedding, embedding the software use is the marriage. Focus on the marriage or you might find yourself considering divorce.

Holly MacDonald is an independent consultant with well over 15 years of experience in the learning & development field. Holly is a bit of a techno-geek and can often be found playing online. When she steps away from her computer, she spends time outside: hiking, kayaking, gardening and of course walking the dog. She lives on Saltspring Island and is a leader in the live/work revolution.

Related Posts

Share

Tags: , , , ,

Category: Blog

Comments (2)

Trackback URL | Comments RSS Feed

  1. Jodi Bakken says:

    Thanks for these strategies. I especially agree with providing various communication vehicles, spacing out the training sessions and giving basic need to know skills. Too often it’s a day long training session, a month later when the software is rolled out, and many bewildered employees that have forgotten everything learned in a cram session!

    • Holly MacDonald says:

      Thanks for your comment Jodi – you are so right. Also most software training is organized by feature/function, not by work task/process. Add that to the list if you are designing the training.

      And I love the term “bewildered employees”.

      Holly

Leave a Reply




If you want a picture to show with your comment, go get a Gravatar.