---
title: "Incorporating Learning into Tech Comm Deliverables"
date: 2012-11-26
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2012/11/26/incorporating-learning-into-tech-comm-deliverables/
---
# Incorporating Learning into Tech Comm Deliverables
![An action-based model for learning](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/act-reflect-learn.png)

The keynote speaker presented a model for learning that included five steps:

- Act

- Reflect

- Learn

- Plan

- Anticipate

The Plan and Anticipate steps seem nearly the same. And I'm not sure step 3 is legit, because how can "learn" be a step in "learning"? But stick with me, because I really like the first two steps.

The speaker explained that this model of learning focuses on "action-oriented development." He admitted his bias about the importance of experience in learning. He also emphasized that unless we take the time to *reflect* on our actions, we don't often learn from our experiences.

Given that I don't include any activities for acting or reflecting in my help material, I mulled over this model for quite a while. By not incorporating these elements, am I excluding what would otherwise allow my users to learn? Why isn't learning a more important consideration for the way I develop my help material?

## Attempts at Integrating These Elements

While I was about on lap 20 at the pool the other night, I realized how to integrate both the action and reflection components into help material.

The first component, Act, can be incorporated by including some sipmle practice activities below tasks. This is not difficult by any means. If you can provide a sandbox environment for users to explore, all the better.

The second component, Reflect, requires more tact. I don't think I could incorporate reflective questions in a help topic without sounding corny (e.g., How did creating a new widget make you feel? What did you learn from your experience in adding a new administrator?)

However, if we alter the reflection element a bit, changing it to "Real Scenarios," it sort of works.

Mark Baker recently wrote a post that's relevant to this point about reflection. His post, [The Real Docs Need Is Decision Support](http://everypageispageone.com/2012/11/05/the-real-docs-need-is-decision-support/), talks about the need to go beyond technical instructions and instead provide users with decision-making information for real business scenarios. Mark writes,

> My field is software development, after all, and not everything in the software development world is done through a GUI. For programs, scripts, and command lines, the mechanical details of command syntax have to be clearly documented. But even where documentation of mechanicals is required, it is never enough. The real tough parts of these tasks are the decisions, large and small, that have to be made along the way — decisions as large as whether and when to do the task at all, to as small as how to choose the right value of an individual field or parameter.

Perhaps the reflection component, so critical to learning, could be included as an exploration of how to apply the technical knowledge to real business scenarios? The basic outline of a help topic might look like this:

- How-to Steps

- Practice Activities

- Real Scenarios

For example, instead of the corny questions I posed above, I might ask the following:

- How can you use this widget during the sales cycle to reduce communication overhead?

- How many administrators might you want to designate to help keep the data up-to-date?

I'm not sure that merely asking the questions provides the business decision support information that users might need, but it's a step in the right direction. (Perhaps a real rather than fictitious scenario might be easier to model.)

## Why Help Fails

Mark's post emphasizing the need for business information hits on the [findability theme](https://idratherbewriting.com/2010/05/17/new-series-organizing-content-organizing-content-1/) I've explored on my blog at length. If users need business specific information, not just technical how-to instructions, then their searches for this information will fail if the help doesn't include this information. Help will end up being a set of mostly obvious topics (except to tech novices) that fail to have any valuable information.

We talk a lot about different techniques for findability — including indexes, glossaries, organizing the content well, etc. But the largest factor in that equation is the content itself. If the content doesn't address the real questions users have, it doesn't help users. They won't find their answers in the help because the answers aren't in the help.

## Why We Omit Business Information

Why exactly do we omit this kind of business information? Because it's hard to write. I once worked on a sophisticated traveling/scheduling application that had an accompanying binder written by the department's secretaries detailing very specific procedures and workflows that weren't part of the application's functionality. Information such as, send "John" a reminder e-mail once you put the report in his inbox," or "The information must be included in the Y report and sent out on Monday; then wait a couple of weeks for it to process," and "Betsy is the one who processes this information and you can call her at 2-5555 with any questions," or "The yellow sheet at the back is the only important information in the report...."

That kind of stuff. I said I'd have to move in to their department and live among them for a few months if they wanted me to document their business process. (I never did.)

In a previous job, I wrote documentation for financial analysts. One time I remember documenting a short sale analysis application. Not having a Series 7 license myself, I found a lot of the concepts difficult to understand. I was grateful enough to correctly document how the application worked. But expanding the help to include advice on short sales and stock trading scenarios as it applied to the application's tools would have been somewhat miraculous. Although it would have been great to include this information, doing so would have required a lot more knowledge than I had.

In short, we omit business information because this kind of information is hard to figure out. It's often specialized to a specific group or industry, and it changes periodically. It's not something you can figure out by merely playing with the application on your own, which is how I like to discover a lot of the help information. You have to milk business relevant information from a SME, if he or she decides to explain it to you.

Additionally, business information for one group may vary for another group. If your application is used by a variety of people, from companies in Europe to non-profits in Canada, no doubt the business processes for each group vary. How then can you write relevant business specific information if this information is so variable?