Teach solutions, not software

I love software training. And I hate software training.

My life in elearning began when I discovered Lynda.com in 2004. Since then, I’ve consumed more software training content than any other type. I learned Photoshop and Illustrator with Deke McClelland. I learned Final Cut Pro with Larry Jordan. And my After Effects skills have benefited from too many authors to count. When I pivoted my career to software development, great trainers like Simon Allardice, Jonathan Mills and Kevin Skoglund helped. I truly owe my career to the great training available.

But boy, most of the software training out there is awful.

Bad software training is everywhere

Have you ever taken a course like this?

It's a "Beginner's Guide". Each module covers a different feature. The order doesn’t really matter—each feature is explored for 10 to 60 minutes and then abandoned. The examples are contrived and unrealistic (let’s practice the “line drawing tool” by drawing random lines everywhere!) The host rambles through videos which are way too long. And there's the gatekeeper, that gigantic, life-sapping ogre called “An Overview of the Interface”.

"That covers the File menu, next let's move onto the Edit menu..."

"That covers the File menu, next let's move onto the Edit menu..."

This course pattern is everywhere. And it’s getting worse. These type of courses are created so frequently that rookie course authors treat them like best practices and emulate them, adding more garbage to the pile.

Authoring a course is a long process and things can go wrong at any point. But these courses make their fatal mistake at the very first step: they try to teach the software.

Wait. Shouldn’t software training… always teach the software?

Software are tools

Think back to a tool you know how to use. Now think back to how you learned to use it.

Take the hammer. I'm sure your hammer story is unique but I’m guessing you didn’t see a job posting, read that applicants should have “hammer skills”, took a quick crash course on hammers, and started using your hammer.

"Chapter 3: Maintaining your hammer for peak efficiency"

"Chapter 3: Maintaining your hammer for peak efficiency"

Of course not. We ignore tools until there is something we want to accomplish with them.

You learn kitchen knife techniques when you get sick of making a mess cutting an onion.

You learn how to use a lawnmower when you have to mow your lawn.

And your first experience using a hammer was to construct something.

This way of learning how to use tools is completely natural. You have an intrinsic motivation ("I want to build a go-kart.") you encounter a problem ("I need to affix these two pieces of wood together."), and a tool presents the solution ("This hammer should do the trick. Whack-whack.").

Why don’t we teach software the same way? Sure, a hammer is quite a bit more simple than something like Photoshop but they’re both tools. We don’t need to teach one tool with different techniques than for another tool.

So why do we?

One tool, multiple solutions

You will not see a job posting for “hammer skills” but it's not uncommon to see help wanted for “Photoshop skills”. An aspiring applicant might then seek out Photoshop training. The process is simple. They type “how to learn photoshop” into Google, they find a course with an attractive title like “Master Photoshop in 10 Hours”, and they start learning.

It can work. A motivated learner will come away with the skills. But not before a frustrating 10 hours because generic software training like this is trying to be all things for all people. And that's a bad approach.

Let’s continue with Photoshop as an example. It is a tool but it’s a tool used in many different solutions. It’s used by photographers to improve their photos. It’s used by designers to make posters, pamphlets, book covers, and more. It’s used by painters and illustrators to draw, sketch and paint. It’s used by game developers to create textures.

I’m just scratching the surface.

All these people, with all these different intrinsic motivations, come to the same tool seeking different solutions. If they don’t know how to use the tool, they find software training. And that training, if it’s generic, has to serve all of these different types of learners equally.

I don't apologize for this overused meme.

I don't apologize for this overused meme.

It doesn’t work well. It’s not just round pegs being shoved into a square hole. It’s heart pegs, star pegs, triangles, spirals, ovals, octagons… they all try to make it through the square hole. The first thing learners lose is their intrinsic motivations. The designer, the painter, the photographer all must go through the same training. The training has no way of knowing who they are or what they want. It needs to be generic. It needs to be one-size-fits-all. The best way the course author can figure to achieve this is a dull tour through the main features.

You might think Photoshop is an unfair example, being such a complicated program. But I’d argue that even extremely simple software can have surprisingly diverse use cases.

All Microsoft Word users can be generalized as "needing to write." Surely one size could fit all there?

But consider how you might teach an aspiring author compared to someone trying to design an attractive newsletter. Both use Word, but those objectives should inform everything about your course, from the detail you put into the module on formatting, to the progression of topics, to the list of features necessary to cover.

You don’t need a degree in instructional design to realize that an author cares very little about colored borders around their words, while making text pop is extremely important to the newsletter designer.

Or take software like Final Cut Pro. “It’s for editing video”, you say. But how would editing a short film be different from editing a vlog? (Hint: it's very, very different!) And that's not to mention the other types of non-editing jobs which also happen to use Final Cut Pro.

Software are tools to solve multiple problems. They shouldn’t be served by a single type of training.

Teach solutions, not software

One-size-fits-all courses happen because the author made a decision. Whether they meant to or not, they tried to teach the software, not the solutions.

The problem manifests itself when you decide to create a course with a vague concept like “Photoshop for Beginners”. That vagueness forces you to compromise on every aspect of your course. As author, you simply don't know the following:

  • What does the learner want out of this course?

  • Which features of the software are important to cover?

  • What type of examples or projects should I use in the course?

  • How can I tap into the learner’s intrinsic motivation?

Those seem like pretty important things to know!

Without a concrete solution in mind, you can only guess. But by simply changing your course concept to something targeting a concrete solution, such as “Creating Game Textures in Photoshop”, you instantly gain a crystal-clear focus that will improve your course in countless ways.

What does the learner want out of this course? The want to know how to create game textures using Photoshop.

Which features of the software are important to cover? Only ones related to creating game textures using Photoshop.

What type of examples or projects should I use in the course? How about you make some game textures using Photoshop?

How can I tap into the learner’s intrinsic motivation? They want to make game textures and you’re going to show them exactly how to do that!

The answers are obvious. They're mind-numbingly simple. But because you know them, they will inform every module, every lesson, every minute... The entirety of your course can now get your learners closer to their desired solution. The end result is something that is a pleasure to learn with.

You are not your software

Up to this point, I've been looking at this from the learner's point of view. And I strongly believe that empathizing with your learners is the most important tool in your toolbox. 

But what about you? You, the skilled professional, who came about your software abilities by hook or crook?

If you're anything like me, teaching what you do for a living is a much less intimidating prospect than teaching all about the software you use. 

I know Adobe After Effects better than any other piece of software. For over ten years I've used it for business and pleasure, nearly on a daily basis. But my expertise is strongest as it related to the solution I needed it for: creating motion graphics.

At one point I got the idea of creating a course on After Effects. If I were qualified to teach something, surely it was that. But even with my constant exposure to the software, I found myself needing to do a lot of research to get up to speed on things that I didn't use regularly. Things like correcting video footage with technical problems, full-blown special effects like you'd see in a film, integrating 3D objects... I had complete confidence in creating motion graphics, but that's not what everyone needs After Effects for.

In other words, most of my expertise would be wasted on a beginner-level crash course in After Effects. And I wasn't good enough to teach other beginner-level aspects without research.

So what were my options?

I could press on with my course, teaching general After Effects skills to whoever wants it, never really speaking to the subject that I have expertise on, passion about, and a lot of insight into. 

Or, I could take my own advice. Let the special effects people teach special effects to those who want it. My audience is those looking for a motion graphics solution. That's who I can speak directly to and I'll be able to utilize my unique perspective and experience solving the same type of problems they want to solve.

Look at your own skill set. If it's just a list of software you're selling yourself short. Go deeper than that. You have the most valuable experience solving problems. And it's way more valuable to share those insights, than to regurgitate information that could be looked up in the manual.

Reaching new eyeballs

“Ah,” the SEO-enlightened amongst you say, “but a broadly-defined course has much more universal appeal than one with a narrowly-defined scope.” To you, I say “touché”. If you manage to create the definitive course for a software, you will have captured an enormous audience.

But is a definitive course even possible anymore? Unlike 2004, learners have a lot of options for software training. Lynda.com (now LinkedIn Learning), Pluralsight, Udemy, MOOCs, and even good-old YouTube. Chances are, unless you’re developing training for software that is brand new, the competition to be the “definitive” course is too tough. You would also struggle to differentiate yourself from many other similarly-named courses which all claim to help you “Learn”, “Master” or “Get Started” with some software.

Good luck getting a slice of this pie!

Good luck getting a slice of this pie!

But even though the potential audience is less, a solution-based course can be more easily found by those who want it. While many learners will find your course through the software itself (searching “learn photoshop”, for example), now a different group can find it by searching for the solution.

A course titled “Creating Game Textures in Photoshop” may get less traffic from “learn photoshop” queries than, say, “Learn Photoshop Complete Mastery Course”. But in exchange, it will appear in queries such as “how to create game textures”. You will find learners who are motivated by the solution. They might not have known that the software could be that solution, or didn’t know the software even existed! Either way, they can now find their way to your course. It’s a calculated trade-off, but one that will deliver a more motivated audience overall.

Loving software training again

15 years ago, software training was almost exclusively the realm of big books, expensive classes, or on-the-job training. That all changed. And the world is better for it.

But more of the same isn’t the answer anymore. To take the next step forward, we must look past the software itself, through the eyes of our learners to see the solution that software represents to them.

That's why I call for software trainers to ditch the one-size-fits-all courses that consistently fail to be something for everyone, and instead focus on concise, exciting learning experiences built around real solutions.

Then maybe we can all fall in love with software training again.