Software applications for the general public and businesses are increasing daily. They can be applications in phones, in watches, in games, in computers, and through the internet. Whatever the application task , it has created an ever-growing market for voice over talent doing e-Lessons and “How To” videos to explain how to operate the application. It also presents a perfect opportunity to discuss how to approach scripting and voice over for this growing market. Whether it is an e-Lesson or a “How To” video, the considerations I will touch on are the same for both. This is because we are talking about instructions, not how they were produced. And, these considerations can be applied to the writer as well as the voice over talent. So, from this point on, instead of saying “e-Lesson” and “How To” video, I will refer to what we are really talking about: “instructions”.
Know Your Audience
Today’s application instructions for products and businesses, are not geared for the individual who is tech savvy. That said, many will jump to the conclusion that these instructions are only for adults over 40. This is not necessarily true. Obviously, the younger the user, the greater their tendency for curiosity and experimenting. This is not the type of user that needs (much less wants) instruction on using a software application. But there are many individuals under 40 that have not had opportunities to use much software. They may use computers, and be on some form of social media, but that is often a far cry from the ability to easily understand many of the new software applications. Further, there is a big difference between software for business and software used by the average consumer. So rather than judging the audience by age, there are several other considerations that may more accurately determine your audience type and how to relate to them.
Is the application filling a niche in a certain market? This might indicate the type of individual you are instructing. For example, imagine there is a totally new type of product for deep-sea divers. It is an underwater visor, where calculations of the depth, air, time and weight display critical information within the diver’s line of vision. This would tell the script writer and voice over talent that the technical level is precise and the terminology very specific. In this type of situation, it would require the writer and instructor to research deep sea diving. Maybe even talk to an experienced diver. Listen to their lingo. Pay attention to the terminology used when referring to an operation or technique needed for your visor. The ability to “talk their language” helps their comprehension of what you are instructing. It will also tell you what areas they will pick up easily and what areas might be new to them. In that way you can sharpen the focus on what they need to learn. Be especially careful about the words you use. Many words we use casually, like “air” might be too vague for a science depending on finite calculations and chemistry. The one caution would be to make sure the words you pick up from conversations with them are not just local slang – where deep sea divers in another place might not understand.
How Much is Enough
Say there is a new product designed to simplify and improve on a well-known process. Here again, the terminology would be specific to the process, but the goal of the instruction should focus only on how to achieve the basic functionality. Meaning how does the prospective user do the same well-known process in this newly designed product. There are 2 very different prospective users this applies to and both will want to learn this information for 2 very different reasons.
The first, and maybe the most important, is the prospective user of a business process. As a rule, this person has done the old process a great deal. They know the old process intimately. They will not want the instructions so in depth that the lesson becomes more time consuming and complex than the original process. This is not to say the new software itself is simplistic and basic. It could be an inventory application that can go far beyond just identifying the stock on-hand. Maybe it is capable of very complex tasks, such as integrating with sales and automatically reordering on a rating scale. But the user is not going to begin using the app at the integration level. All they need to get started is to identify how their current process can be done on the new software application. The more complex features of the product can be learned a little at a time. The real key here is to remember we are asking the user to change, and change is difficult. If the new process is even somewhat different, it can be challenging, often intimidating and sometimes they will even feel the product threatens their job security. So, go easy. Make it basic. It won’t hurt to give a little sales pitch about how much it is going to make their life easier, or safer, or make them shine to management. But don’t go overboard being cheery or telling jokes, they probably will not be in the mood for it. Change is often scary, maybe even fear laden.
The second prospective user is the individual consumer in the marketplace. Say the product is a revolutionary new car, all electric, where the actual mechanics of it is nothing compared to the software that controls it. I’ll use a Tesla for this example. The buyer already knows how to drive and is practically drooling to drive the Tesla off the lot and show it off. At the price they paid, you can feel assured they know its capabilities (probably already went through the car manual before they got there). But, unlike manuals that break down every control into separate details, you will want to pull it all back together by walking them through how to get to each control. The new Tesla does not have a dashboard per se, most of it is all on a computer screen and 2 levers around the steering wheel. Unlike a gear shift on the floor that has the familiar H pattern, or the steering wheel shift used to move back and forth between the P and D on a dashboard, the Tesla shift lever only wants up, down or in. The computer screen is not navigated like software applications with a menu across the top and it does not come with a mouse or touch pad. Most of the controls are reached by touching pictures or symbols. But, like most applications today, there are many ways to access the controls. Your job is to walk them through the main way to access the control groups. Then, you might repeat your walk through, adding in a secondary way to access key controls. It is all about keeping it simple. Now that they are getting the real thing any minute, you don’t want to keep them waiting so quit while you’re ahead.
Why Take a Chance
The use of acronyms or abbreviations can be very risky. The same abbreviation or acronym you know and plan to use in your instruction can mean something totally different to the potential user. For example, say soon after the instruction begins you throw out an abbreviation for some task in the application that is common to technicians of this product. But, the potential user of this product automatically recognizes the abbreviation as something else in their world. Generally, it will take a bit of time before the user realizes you are talking about something totally different. Don’t kid yourself, this happens all the time. When a user is clueless about a product’s operation, they are primed to pick up on anything recognizable to them to help them understand. By the time they recognize their interpretation is not fitting with the instructions, the course of the instruction has continued well past that initial abbreviation.
If this is in a real-time classroom environment, it might have been worse. The instant after an individual realizes the abbreviation is not what they thought it was, they also notice that everyone else “appears” to be understanding everything. At that point, social alienation is a real possibility to them. The individual has totally lost the context of what is going on and now is playing social scenarios in their head. With recorded instructions, the user can at least back up the instruction and re-listen for this new type of meaning for the abbreviation. But even though the user could recover from any misinterpretation, why would you want to risk that? Time is money, and a poor instruction impacts the product.
Misinterpretation is particularly risky when instructions are geared for State and Federal institutions. There seems to be a never-ending supply of people, places and things in government that can only be identified by an abbreviation or acronym. In fact, if you took a poll, you would probably find that few will be able to state the full name behind many of the older abbreviations and acronyms.
The real solution is identifying any new or easily confused terminology at the beginning of the instruction. Much the same as I did in the first paragraph of this blog. Instead of continually saying “e-Lesson” and “How To videos” I pointed out that both were only the means used to convey instructions and what we are really talking about is the actual instruction itself. Then I noted that for the remainder of the blog we would refer to what we are really talking about as “instructions”. What is important is not the manner of delivery used, but what they both do. If you have an abbreviation or acronym for your product, identify it at the start by its full name, then say what you will call it throughout the instruction. This also goes for a process that has an abbreviation or acronym. Highlight the abbreviation or acronym and explain what the process does that initiated the abbreviation or acronym. This explanation will also help to cement the name to the process for the future. And, the time you spend on that explanation has a positive impact on both money and the future of the product.
Good luck! And, keep on instructing.