The Use Case for a Learning System

The Use Case. Probably the least fun experience you will ever have when looking at or considering any type of learning system (LMS, LXP, EXP, Learning Platform, Craig’s Javalinas R US, etc.). The basics of any use case, is, to define at least at the very early stages, whether or not you qualify, for the conversation to continue. The majority of vendors will continue, regardless of what you espouse. Now, if you want employee learning only, and you go to a vendor who only does customer training, then the initial “use case” rejection (politely) is understandable. Ditto if you want employee learning for retail operations and talk to a vendor who only works with associations.

I had an experience a while back with one vendor, who “pre-qualified,” you, based on your use case. If you passed the first round, then, and only then, did you get to talk to a salesperson. Considering the person pre-qualifying you, is not at the expert level of customer training, I found this extremely displeasing and unsettling. The vendor is Skill Jar. The way this happened? Filling out a request for more information/demo (can’t recall their terminology). I tried to think of any other service out there, where you have to go thru pre-qualified with a person, before you can even get to talk to the salesperson. For the longest time, I was stumped.

Then it dawned on me. Credit Cards. You are “pre-Qualified,” but still have to pass the application process, before you get qualified, so really you are not pre-qualified. From our industry, including learning systems, learning technologies, content providers and so on, I have never in my 23 years in the e-learning industry, let alone training, ever had to go through a pre-qualified approach. Nevertheless, this whole angle was around a use case.

What is your Use Case?

When I talk to folks at trade shows, via readers contacting me, LinkedIn and so forth, I will hear, “well, there isn’t a system out there, for my use case.” I will then inquire some questions, just a few on what their use case is. They will provide the information, and each time, I will tell them, there are learning systems out there for that use case. Plenty are surprised, and state they haven’t found any, which isn’t surprising, since there are so many out there, and it would not be unexpected for folks to look for all of them – rather to focus on the ones they are aware of, or someone said you should check them out – and that solution is known.

The basics really is that you want to train your employees or customers or members. Or you want your students to learn. Perhaps you want the “audience,” to learn new skills or train them around new skills. Perhaps it is all about upskilling, or reskilling or acquiring knowledge based on their interests (a novel idea, I know – and rarely sought, sadly).

When I ran training at numerous companies, I would get the use case inquiry. And my retort was never in-depth, it was the basics honestly. I knew what I wanted, what I was looking for, and readily admit got irritated when a vendor would ask for further information because they just desired to know more. As if, that information would be the deal breaker for them. I never sought out systems that didn’t apply to the basics – such as seeking a system for customer training, and eyeing one that I knew was for employees only. Or seek out a system with NexGen features and look at ones that lacked anything along those lines – this could be achieved by just a read on their web site, or a reach out via e-mail around a few questions.

Times though have changed. Nowadays you just can’t get by with a use case that are the basics. The vendors really need to know more about the use case. They push for it. Angle around it, and the ones who know how to work it, are able to apply their system around that specific use case. It’s like magic.

With my clients, I always stress that they need to provide a very in-depth use case. This is to assure that the vendor clearly understands everything. Ambiguity is the downfall for so many people who pick a system, only to realize down the road, that by not being clear enough, they made a mistake. Getting out of a contract in our industry is very difficult. Thus, stewing and griping within yourself, are the only options, besides telling others that they system is perfect.

I wish I could tell you to just go with the basics and then get irked when the vendor wants more information. “How dare you,” you think. Then you ponder whether or not, dinner will be takeout or made.

Thus, when creating a use case, regardless of your industry, approach, location, user base type and size; you must go full in-depth. Extensive is always better – if that extensiveness is detailed. If it is something like, “We need the ability to add users to a group,” then that is not part of a use case. That’s criteria. Criteria you can just see when you check out a demo or blast over an RFP (after you take a look at the demo, although way too many people do it the opposite way).

A Use Case Should Be

• Clear
• Right to the point for the audience – what they are doing now, what is working, what isn’t working, why isn’t it working, what you believe would solve that problem or problems or issues (depending on your vernacular).
• Response driven – think from the vendor standpoint – what would they need to know to understand your challenges, your focus, approach, and where you want to go
• Go detailed – then hand off your use case to someone who is not working in your department/division, heck even your company – and ask them if what you wrote is clear for someone to understand what you are trying to achieve. Excluding terminology (which that individual may not know), is the writing align, does it make sense, and would someone, whomever reading it, get “it.”
• Audience Driven – This is a bit different than the audience earlier bullet point. Here you go nitty gritty with your learners. Use fictious names – not just “our accounting department.”

Example:

Bob who is a senior manager in our accounting department currently uses spreadsheets to calculate how many of his people complete a training session. He does not know the dates of the sessions, nor whether or not the employee, understood and comprehended the information. He is unsure of the skill level of his employees, especially those who are new.

Sarah, who is brand new to the company, is unsure whom to report to when she wants to learn a new skill. She has multiple managers, and each one, wants to know what she is trying to accomplish. One of the managers is very detailed-driven and seeks reporting around XZT (you put in that information). The other manager tends to be overwhelmed, and only seeks reports around attendance.

Each of these examples – will provide the vendor with crucial information. In the latter, a vendor should immediately recognize that you will need a way to send different types of reports, for each of the managers. One manager wants a lot of details – thus it may be multiple reports; the other – an attendance report. A vendor may ask, how often will they need the reports – daily, weekly, monthly, etc. – Then you, can respond, or if you unsure, ask. My gut would say weekly, and until the manager says differently, then weekly seems to work. I could equally ascertain that because manager B is overwhelmed, a weekly report, or a report that goes out every other week, would suffice. Manager A – daily reports, with a comprehensive one weekly – nevertheless, most folks just want weekly. With the above scenario, the details Manager A wants would be provided in the scenario – again, the vendor should be able to get “it.”

With Sarah’s challenges around the multiple managers angle, well, you can assist from the skills standpoint – by providing specific reports around the skills. Again, this is just a scenario angle – so go further when you can.

The Bob scenario is easy to figure out. Besides him living in the stone age (sorry Bob), I can tell you, there are plenty of folks out there right now, at many companies that are like Bob. If a vendor is strong in skills they could present this information. A vendor might follow-up around what specific skills – but again, you could go more in-depth when building out the scenario.

Similar could be around Dallas, who wants to learn a variety of new skills, for their job role. Currently, they work in sales, and is unsure what content/courses they will need to learn these new skills. The skills include the usage of Salesforce and how to apply it to their job when receiving leads.

Again, a vendor can gather a lot of information here.

• If you need integrations or seek integrations – tell the vendor in the use case. This is different from criteria IMO, because it deals with technical information – that is crucial for any vendor. If possible, always send them ahead of time (with the use case), any details you have around the other platform, especially what data you will need to go into or out of the other system. Vendors will know the common ones – ADP, Workday, PeopleSoft, Oracle, SAP, Lawson and Salesforce for example. However, they may not have heard of ZambaPeanuts. Thus, the more you can provide, the better. If it is a common one, than provide the name, and what you want to do with your system, tied to it. Always be very clear and detailed. Remember no ambiguity.

In any use case, identify the number of people who will use the system in a calendar year. Think this way – one username, one password. Access as much as they want, as often they want, and consume as much content they want each month. If you do not know these numbers, give an estimate – i.e. on the user base. The latter is very common with customer training or client training. Because you want to grow that audience. But you should have a baseline. Go conservative here, and not pie in the sky. How many would you feel comfortable with providing (think of your budget here). For employees, way too many people provide the same user base size each year (always seek a three-year deal), ignoring or forgetting that your company probably will hire more people within those next few years. Thus, there will be – you hope an increase. Nobody sits at the same numbers of employees every year. So, why would you think that way for your learning?

Have another system?

State it in your use case. Right up front. Be able to provide in the use case the following.

• When does your contract end?
• Will you need data to be moved from that system to the new system? Data could be what content they have completed, or taken, their profile information and so forth. Again, be specific. Vendors will want to know this, so get it out of the way early. How many people will need to be moved over? People in forms of data. If you have 5,000 employees in the system, but only 2,250 are taking content, but you want all the 5,000 in, then you will state you want to archive inactive users. A vendor worth their salt, as they say, will not charge you for the inactive – when you want to buy seats (some vendors call them licenses).
• Any other pertinent information that you feel is important for the vendor to know. You could mention the other system(s) you need to be integrated with; the content providers you have and want to continue with (strongly recommend stating so), implementation timeframe (a must!), process for making a decision (relevant), next steps – essential. If you don’t know some items, then note this in the use case.

Example for the beginning of the Use Case

We are a company in the consumer goods market (greeting cards), that will need to train our 15,004 employees. Currently, we have VoodooDog LMS and their contract ends in three months. We want to make sure that the data covering blah blah, is moved over to our new learning system. At this time, we are using Workday Modules – ABCDESF, SharePoint for ABCSD, and WidgetMania as our CRM.

Our timeframe to select a new system is blah blah. As such, once we select a system, sign a contract, and sign-off on the project plan (if applicable), we will need the system to be live (with our employees/customers/students/members, etc., in the system taking courses) by X.

Our focus for the decision will be based on:

• Meeting our use case(s)
• Understanding us, and what we seek to achieve in the next three years
• Alignment with our learning commitment and processes with our audience and organization’s culture
• Forward-thinking approach with your system
• Your company’s philosophy around support, and the mechanisms you will provide in case there is an issue
• The level of training our administrators will receive and on-going training

And you want to add whatever else. Remember support is the #1 reason why people hate their system, so make sure you are clear with your expectations. Training is vital. After all, you are in the learning and training business, so if you think it isn’t vital, nor important for those admins, which might be you, uh, you need to change departments. I am fully aware that learning systems could be in marketing, or sales, or product, or HR, and those folks know nothing around sound L&D or Training methodologies. Thus, training is CRUCIAL.

Never tell a vendor you budget (not in the use case, not in the decision-making process, not in general conversation over the weather in your town). The vendor will likely ask – tell them it is about finding the right system for your audience and leave it at that.

Bottom Line

This use case approach is very likely far different than what you are used to. It may be so out of the box, you will say, nope, can’t do it, won’t do it, and I need to say we want a modern system with AI and blah blah blah. First off, every system is going to say they are modern, even if they aren’t. Secondly, a vendor may not have AI now (it is very early for our industry, let alone everywhere else), and thus could get cut out, early on – because they do not have it today. If a vendor has AI, they will mention it to you at some point during the conversation; heck they may state it on their web site.

One thing I would note though is you want a system that offers a Creator component. Creator means that the end-user can add their own content, create their own content either whether in the system (ideal) or externally, upload it via a mobile device, share the content with others, and communicate with those in their cohort – ideal, or group (old school, but works) or community, and you want to make sure that the system offers a contextual learning approach and experience.

I mention Creator because to me, this is the WHAM and SLAM (in a good way) for the industry to move forward, that aligns to what the Tik Tok, Instagram, YouTube audiences see and experience every day. Creators dominate the world, outside of our own learning/training space.

Again, this to me, doesn’t fall under “criteria” which is really specific functionality, rather it goes into your use case – easy to apply by the way.

If I am a vendor, I am using “Creator” as a key term, if I can do all the above.

Because a vendor will always have a use case themselves.

Just nobody every asks them.

E-Learning 24/7