Don't let your solution be part of the problem

It's just like Grandma used to tell me: Any conversation with a product vendor that reminds you of the importance of empathy is a good one.

Recently, I had a brief chat with a vendor who was promoting her company's learning development tool. The conversation started when she asked me what we were currently using as a content development solution. When she heard my answer, she rolled her eyes and cringed. She then told me about her company's high-tech, cutting edge, fully immersive virtual reality solution, and the novel things that can be done with it when applied to training and environmental simulation. All of it was impressive. None of it seemed relevant to my current needs, based on her description of the tool. My immediate reaction was not only negative toward the conversation itself, but also, surprisingly, toward the tool. Although in general I'm captivated by the potential of VR and its impact on learning, it suddenly felt like a flash in the pan.

I didn't want to dismiss the vendor, because I wanted to be open to the idea of an approach that I hadn't yet considered for our learning products. I found an opportunity to tell her what we were doing -- enabling users of SaaS and desktop software to be proficient at their jobs using this software -- hoping she'd tell me how VR, which I understood to offer breakthrough opportunities to help learners practice spatial-related tasks, might meet our learner's specific needs. She responded by offering an example of how someone might use VR, perhaps to simulate walking through a door and into a new room. It took a little more back-and-forth before she understood and acknowledged that her company's VR product was not likely to make enough of an immediate impact on the quality of our learning products to justify the investment.

It was a disappointing interaction, and it left me feeling like this vendor wasn't looking to help me after all, but rather, she was trying to convince me to help her by agreeing to buy a product. In short, it seemed to be about her solution, not my success.

As unfortunate as this conversation felt, though, I think there's something really valuable to take away from it as a learning experience designer. We have an opportunity and a responsibility to provide relevant, helpful support to our learners' successes, and that starts with how we approach their problems and how we offer our solutions. Following are a few key takeaways I've been thinking about since that conversation.

Don't lead with a solution

"What tool are you currently using?" wasn't a bad question. It's just not what the vendor should have led with. She didn't even yet know anything about what problems I needed to address.

Often, a customer, client, or stakeholder will approach us with a learning solution in mind. We then have to redirect the conversation by explaining that before we decide on eLearning, a series of videos, a game, a full-day facilitated course, or even a VR environment, we need to take some time to fully understand the problem, first. What do the learners need? Is it a lack of skill, knowledge, or motivation that needs to be addressed? Do the learners already have a strong base of understanding, or is this a large, brand new and complex issue that necessitates in-depth, end-to-end training? Is it even a performance issue that's causing a gap, or is it a poorly designed system that needs to be restructured? We explain that we need to make sure that we are fitting a solution to the problem, not the other way around.

But we need to make sure we're not also guilty of leading with a solution. How many times has your customer come to you with a need and three sentences in, you're thinking about how much this reminds you of an earlier project you finished with great success? Maybe you could reuse some of those templates and update them with your customer's look and feel, or OK, maybe it would be three eLearning modules instead of two, but why reinvent the wheel? Or maybe you learned about a new online tool that will help you build incredible responsive knowledge checks and you're excited to have a new project to try this with.

The risk, of course, is building a perfect solution to the wrong problem. If your product is cutting edge, fun, interactive, and engaging, but doesn't help a learner gain the skill or knowledge needed to reach your ultimate goal, then the product has failed.

There is also the risk of damaging the reputation of the solution, itself. When we poorly assign a tool with great potential enough times, industry interest fades. People no longer see potential. They see a gimmick.

The truth is, we've all been guilty of being too eager to jump to a solution before understanding the problem at some point. Guilty with good intentions, sure, but guilty. We need to listen to our own convictions: Do not lead with a solution.

Listen with empathy to understand

I have to say, once I told the vendor what it is that my team does, it was surprising to hear her support her pitch by offering an example that was categorically unrelated to what we do. It was clear she wasn't listening to understand my actual needs.

Shortly after this interaction, I had the pleasure of attending a presentation on Design Thinking, given by Jolene Rowan. Rowan explained that the first step in the Design Thinking process is all about empathy. Successful empathy requires avoiding some common pitfalls, such as making assumptions about learners' needs and wants, focusing on technology instead of people, and providing the easiest or cheapest solution. Instead, Rowan suggested a few tools, such as empathy maps to understand learners' true needs, thoughts, beliefs, behaviors, and emotions around a task. She also emphasized the importance of crafting learner personas to really help understand who your learners are and aren't. Finally, Rowan encouraged designers to ask stakeholders about what success looks like to them before a project gets started.

It seems intuitive that to build learning products that help people succeed, you need to spend some time learning about who they are, what their motivation, knowledge, and skill levels are, and what success looks like. But so often when a project fails, we can point back to a lack of listening up front.

Pivot as soon as it becomes clear there is a need to do so

Although it took her longer than it needed to, the vendor did acknowledge at the end of our conversation that our customers' decision making and technical aptitude learning needs were not likely candidates for her solution at this time. It was at this point that she referred me to someone on her team who told me about another product their company offered that was much more in line with what my team's needs today are. It was not a new product, it wasn't flashy, but it was much more relevant. Here, after my team's needs were understood, we finally started talking about possible solutions to the need.

This is really tough, but it's important to acknowledge when a solution you've started toward just isn't working and pivot in another direction. I rediscovered the truth of this last year, when I was trying to build a daylong course to be delivered at our company's annual conference. We borrowed time from SMEs, built out an action map over a couple of sessions, and sat down to design the course. Quickly, it became apparent that what looked good in the initial sessions was still lacking focus when we tried to build a skeleton of the course. We were blocked, but my initial instinct was to push through and try to make something work. My boss, however, recognized what was happening and called for a pause. He knew we had to go back to the action mapping session and ask some more targeted questions. At first, this felt to me like a defeat -- we were very all busy, including the SMEs, and now we were going to ask them to spend more time doing what we had just done? -- but it was exactly what we needed to unblock the course. We got a lot of insight from the action re-mapping, and from there on out, everything flowed much better. The feedback from the students who took the course at the conference was overwhelmingly positive.

Incidentally, this is exactly why taking an iterative approach to building learning products works so much better than a strict ADDIE/waterfall approach. Making smaller adjustments early and often based on frequent SME and sample user feedback makes course correction so much easier than waiting until the big reveal when the product is near completion.

In the end, it's critical to remember why we design and build learning experiences: to help our learners successfully address their needs. And you know what? Sometimes that does mean turning to a brand new technology or tool. Innovation is what's given us the means to better, more quickly, and more fully meet learner's needs today, and it's incredibly exciting to think about how breakthroughs in technology will soon allow us to learn and acquire skills through experiential learning in ways that seemed like science fiction just a few years ago. But the technical solution must always fit the learning need, and not the other way around, lest we risk frustrating learners and cheapening powerful tools.

Or, as Grandma always put it: Keeping users and their learning needs in mind catches more flies than vinegar.