I get asked this a lot. Even people responsible for training or user assistance struggle with the difference between the two types of content. I’ve searched for clear definitions with little success—I was looking for something that concisely delineates the difference between training and user assistance in the context of software programs. Does it exist? I couldn’t find it, so, I’ll address the subject myself.

Let’s start with the basics

What is training? According to the American Heritage Dictionary, training is:

Training materials are usually prepared post-development. After a software program (or feature) is developed, tried, and tested, the instructional designer can assess the program as a whole. The writer can prepare content focused on key functionality, the learners’ goals, and provide exercises to cement the learning concepts. Training is always goal-oriented; that is, it’s either for certification or revenue.

What is user assistance? It’s a general term for just-in-time (JIT) assistance for software users. The phrase incorporates all forms of help documentation available to a user, which includes online help, user guides, tooltips, hover help, walkthroughs, guided tours that can easily be dismissed, and feature-specific tutorials.

User assistance = reference + procedures -> for better experiences

User assistance (UA) is prepared with the software development as part of the complete software package. Delivering complex software without any supporting documentation (the how and why, and decision support) can cause users to give up or find awkward workarounds when they encounter an obstacle. A UA writer’s objectives are about the experience and understanding where JIT assistance is needed to get users through the obstacles. It’s help at the point of need in the program.

 

Why are they different?

Training and user assistance serve different purposes. In a training guide, you might teach someone about using the online help: how to open the help menu, the different options available under that menu, how context-sensitive help works, how to use the index versus the search function, and so on. In a reference guide or the online help (user assistance documentation), you wouldn’t do this.

Training teaches someone the basics of interacting with the software, using real-world examples and exercises; user assistance provides detailed instruction or in-depth procedures. You would train me to create a new customer invoice using the software, from timing, to which buttons to click, to any follow-up processes and best practices. The user guide or help topic would explain all options in the Create Invoice page of the software and provide the steps to using the page, as well as links to related topics.

User assistance isn’t just a guide or online help. The research is clear: today’s software users want to read less and do more. They want programs that are intuitive, that empower them, and that anticipate their needs. User assistance is about improving usability. This means that user assistance often comes in the form of good micro-copy on the software page. Good user assistance reduces the need for training.

Knowing your audience

When writing either training or user documentation, you must spend time with your audience to learn their needs. Spending time with them can including sitting with customer service and customer support representatives to listen to their calls, asking customer service or support reps for feedback, actually talking directly with your audience, and reviewing user research. This is necessary to produce documentation that helps, rather than making potentially incorrect assumptions and wasting your time creating documentation that collects dust.

Prioritize your audience’s needs: something that works for a general software user could help the super users (such as management), but if you focus on the needs of the super users, it won’t work at all for the majority of your audience. You may need to create additional documentation just for the super users to focus on their specific advanced needs.

Writing strategically

Some duplication between training and product documentation is inevitable, but as a writer, you shouldn’t be wasting time doing things twice or copying content from one source into another. In some cases, it makes sense to repeat information. But if it becomes the foundation of documentation, I prefer to single source my content with a content management system (CMS) or content authoring program like MadCap Flare.

When writing documentation, I ask: “What information does the reader need in order to understand the instructions I present?”

Tackle this by explicitly identifying your assumptions, and state those assumptions clearly. For example, in a user guide or help topic, introduce the user interface by describing its purpose before delving into procedures to use the interface.

In a training guide, I emphasize the overall flow: “What steps do I do to achieve my goals and why?”

When it comes to training, I’m especially fond of the Minimalist theory of J.M. Carroll, a popular framework for instructional design focused on computer users. His theory states that:

1. All learning tasks should be meaningful and self-contained activities,
2. Learners should be given realistic projects as quickly as possible,
3. Instruction should permit self-directed reasoning and improvising by increasing the number of active learning activities,
4. Training materials and activities should provide for error recognition and recovery and,
5. There should be a close linkage between the training and actual system.

I mention this because it’s another example of how different the approaches are when writing content for training purposes and writing user assistance documentation. There’s a clear line between how the content is prepared and delivered.

Blurring the lines between content types

And yet, that clear line is probably most obvious to people in my field and much less important to the average software user. Yes, there’s overlap between training and user assistance. The software works the same way, regardless of how you write about it. The objectives and approach are different. The point of access is different.

And after everything I’ve described in this article, understand that for your audience, the type of content rarely matters—what’s most important to any audience is getting answers when they need it. Your readers’ objectives are practical: how do I use the software to accomplish my goals? The format in which your readers receive the answers rarely matters to them, as long as they have access to the answers and guidance they need when they need it.

The reasons to differentiate training and user assistance depend on your resources when developing the software program, your approach as a writer, your software company’s directives, the timing of your deliverables, and in the structure of your software development organization.