μεταcole

Most of us who have attended software classes or workshops would know that just because you’re an expert with a software application doesn’t mean you’re good at teaching it.

This applies to most other subjects as well – a history expert or a literature expert doesn’t make them good history or literature teachers.

Except that the situation may be worse for software experts.

The geek species is not known for empathy, and empathy is important for good teaching. (Empathy is also important in creating user-friendly software, which is why most software aren’t user-friendly – but that’s another story.)

Because most software teachers are geeks to some extent, it is no surprise then, that most software classes and workshops are not well-taught.
This situation isn’t going to change overnight, but I hope the tips in this post would contribute to that change.

The tips in this post deal with the strategy or approach of the lesson. I hope to do another post on some tips on the delivery of software classes.

Without further ado, here are the tips:

Help learners answer “why should I bother with this?”

I wouldn’t dare teach any software application (or anything else for that matter) if I can’t help the learner answer the question, “why should I bother with this?”

This is about making the learning relevant. And if it’s relevant, the learner will be more motivated to learn whatever that’s being taught.
If the learner cannot figure out why they should be learning the application or the feature, then you’re likely to lose them very quickly.

If you’re lucky, the learner already knows why, or eventually figures it out on their own, so it doesn’t hurt so much if you miss out this point. If you’re teaching Powerpoint for example, the learner probably already knows that it can help them with their presentations.

But if you’re teaching Excel as part of a Microsoft Office competence program for retirees, you’ll probably have a lot more trouble.

If your idea of making things relevant is to tell them that Excel is “a spreadsheet and it’s important to know how to use spreadsheets”, good luck – you’ll need lots of it.

But if you tell them that Excel is “a program that can help you keep track of your money, including how much you have in your different accounts, how much you’re getting from your pension and investments, and if you’re getting richer or poorer over the years”, they would have a clearer picture of what they’re getting into, and they’d be a lot more motivated too.

That initial reason you’re giving them doesn’t have to give the complete picture. Like in the above example, we know that Excel can do much more than keeping track of money. But as far as learning is concerned, especially with beginners, it’s much better to start with something incomplete but easily within grasp.

Here’s another example. When I teach Photoshop to beginners, I’ll give a brief introduction:

Photoshop, as it’s name suggests, is a program used to edit photos. This means that after you take a photo, you could improve on it, like make it brighter if it’s too dark, or make it darker if it’s too bright. In fact, as you go along, you’ll find that you can do a lot more in Photoshop – you could change the color of a flower, you could make your complexion clearer. But let’s start with the basics first…

I wouldn’t mention that Photoshop can be used for drawing, for painting, for design, until many lessons later, when they are already familiar with editing photos in Photoshop:

Remember in the first lesson when I said that Photoshop is used to edit photos? I must confess that it’s not the whole truth – Photoshop can be used for design too…

Don’t teach feature by feature – paint scenarios

Teaching feature by feature is probably the most common and glaring mistake in teaching software, especially when the learners are beginners. If the class is boring, it’s probably because of this mistake.

This is when the teacher teaches the application by going down the list of features, teaching one feature after another. Some may go down each menu item, or each toolbar button.

This approach is convenient if you want to cover every feature in the application.

But the problem with this approach is that it doesn’t match the mental model of the learner. When the learner uses the application in future, it’s because they have a problem to solve. They have to go through a thinking process that maps the solution with the features that will help them solve the problem.

If they were taught feature by feature, it would take considerable effort and intelligence to pick out the features relevant to solving that problem. It doesn’t occur to them easily that those features (that they’re supposed to have been taught) can actually be used to solve that problem.

So when you do point out to them how those features could be used in concert to solve the problem, they might exclaim, “why didn’t I think of that?”

Perhaps they didn’t think of that because it’s the teacher’s fault.

It would be a lot more useful, interesting, and relevant if you painted scenarios or problems before introducing the application or feature.

So, when teaching Microsoft Word, the typical geek approach when introducing the page break feature is to just introduce it:

To insert a page break, go to Insert > Break > Page Break. See the page break? Good. Try it out, then we’ll go on to the next feature.

Snore. Most learners would just go through the motions, and they would miss the significance of the feature.

It would be far better to introduce a scenario first:

While Word automatically adds new pages for you, as you might have noticed already, there may times when you want to continue on new page, even before you reach the end of the current page.

For example, you may have reached the end of a major section in your report, and you want to start the next section on a fresh page.

To do that, you have to insert a page break. Go to Insert > Break > Page Break.

It takes a little longer, but it will definitely stick a lot better. Even if the learner doesn’t remember exactly how to activate that feature, they’re likely to at least remember that such a feature exist.

Even better, if you have the time, you could make things more interactive and to stimulate more thinking, by asking the learners to come up with their own scenario:

To insert a page break, go to Insert > Break > Page Break. Try this out, then give me an example of a situation when you’d use this feature.

But what if you want to teach a feature, but you can’t think of a scenario that relates to the learners?

Don’t teach every single feature – only the useful ones

It’s tempting to cover as many features as possible, and there’s often some pressure to do so.

I’ve taught some classes where the learners pay for the workshops out of their own pockets, so they want to get the most out of what they’re paying for.

In such cases, I’d tell them at the outset that I won’t be teaching every single feature. After a brief pause to let them regain their composure, I tell them “if you want to know about every feature, you can read the help file. And, there’s not enough time to cover everything anyway”.

Instead, I promise them that what they’ll learn would be useful to them. “We’ll start with the basics, and I’ll make sure you understand the important concepts really well, so that you’ll have a good foundation to build on. Then we’ll move on to the more advanced stuff if we have the time. If not, the foundation you have will help you understand the help file.”

So which features to cover? You should focus on the features that will be most useful to the learner. So if the learners are beginners, start with the basic ones. And if you follow the previous tip and use scenarios, you’ll already have some idea as to which features to cover and which to drop. If the learners are newbies, start with the most basic and common scenarios – these would cover the most useful features.

If you have more time, then go on to other scenarios, from the most common to less common scenarios.

If time doesn’t permit me to cover some other less-common-but-possibly-useful features in detail, I normally spend a short time just “flagging” some of these features.

For example, if I’m teaching Photoshop, I might have taught them the sharpen and blur “filters” (features used to sharpen or blur photos). Photoshop has many other “filters”, but I wouldn’t cover them. Instead, I’d tell the learners,

You’re already familiar with the sharpen and blur filters. If you look at the Filter menu in Photoshop, you’ll see a whole bunch of other filters – each of them will give a different effect to the photo. I won’t cover them, but do go and try each of them out in your own time and play with them to see their effects.

Then I move on to the next scenario.

Conclusion

If you’re already an expert with a software application, teaching it well isn’t a difficult thing once your approach is right.

Take a bit of time to look at your approach, and keep putting yourself in the shoes of the learners (yes try to empathize with them), and you’ll be well on your way to becoming a pretty good software teacher!