IT professionals often lament that users of solutions do not take training seriously nor invest adequate time into learning how to get the best out of solutions provided.

Last week I had a stark reminder of what it feels like to be on the other side of this debate. I recently changed my car, moving from a manual to an automatic transmission and I recognised my own subsequent behaviour as being very similar to how most users approach system adoption.

Fear of change and reduction of influence

While I worried about the lack of control that an automatic gearbox might bring, in truth it has taken a couple of weeks for driving with such a gearbox to become normal and I do not miss changing gears at all.

The car has paddles on the steering wheel which I can use to override the automatically selected gear but I’ve not used them at all.

Important to me

I was excited that, for the first time, I had a system that fully connects to my phone because, for someone used to voice-only Bluetooth connections, smartphone connectivity (Apple or Android) is fantastic.

Surprise surprise, because it was important and new to me, I had that sorted within a few minutes of getting in the car – something I wasn’t that bothered about when looking for new cars became my most important element to learn.

Not important to me

I am not a car person and haven’t ever had an interest in tinkering with them. I simply use cars to get from A to B.

On collection of the car I gave the book a cursory glance, set my driving position, flipped through the options on the screen and that was it. I settled down to my standard ownership approach and happily did just over 5,000 miles in the first 10 weeks.

The panic

I jumped in the car one Friday night, pulled off my drive and got an alarm that one of the tyres was below pressure and that I should pull over and change it. Typically, this happened the night before we were due to go away.

That’s when I then received a cold dose of reality; I didn’t know how to change a wheel, where the jack points were, if I had the security wheel nuts, if I had a full replacement or a half wheel replacement or even if the car had a jack.

Never mind I thought, it can’t be that hard.

Until I opened the boot (notice still no manual) and there wasn’t a spare tyre in sight! Instead there was a black box gadget which contained an electronic pump with a black bottle. I’d never seen anything like this so at 9pm on a Friday night I could be found with a torch, manual and some profanity, trying to work out what to do.

It was at this point I was struck with the thought that this is how users must feel when new IT systems come into play without adequate explanation and support.

My interactions with the garage had been very focused on whether the car would do the mileage I wanted, the change from manual to automatic transmission and the cost of purchase and ownership. At no time did the garage tell me what I needed to do to look after the car, change tyres, etc., and I hadn’t even asked.

Perhaps I had been overly dismissive of the manual provided (but who really reads a 500 page tome) and perhaps the garage expected me to thoroughly investigate the features of the car on my own volition – but given I was changing my car because my old one was showing signs of collapse and I’m not a car person, those things didn’t occur to me.

Both of those views are valid, but it didn’t help me feel positive towards the car that fateful Friday night.

How to help users feel more confident

It is important to remember when making any significant change that the consumers of those changes are busy getting on with their day jobs and no matter how important things seem to the project team, it is human nature for the users to almost ignore training or manuals until something happens which forces it – effectively both parties are on the back foot in reactive mode. Some important points to remember:

  • Manuals will not be read until they have to be and then it’s not a positive experience.
  • Every user will have things in the system which are important/interesting to them and which will naturally be more motivated to learn how to use.
  • Most systems are highly complex and provide features which will not be used. However, users may be missing out because they can’t see the wood for the trees.
  • People remember what they are shown more than what they are told or what they read.

When undertaking any form of change it is best to:

  • Engage with the user base early and identify concerns that need to be addressed and ensure these are covered during training and post-go-live support.
  • Undertake demonstrations and training on regular functions so users know what to do when they need help.
  • Identify areas of ‘hygiene’ to enable the users to operate the system in the way it was envisaged. For example, best practice data entry, any regular maintenance procedures and any known work-arounds should they be needed.
  • Create how to documents (quick reference guides) to assist when something goes wrong and a mechanism for users to quickly find them in their moment of need.
  • Include screenshots in the guides and keep them as short as possible.

Putting yourself in the position of a user of something new will enable you to more easily understand how you can help others in an effective way.