Contextual help isn’t new. The notion of giving a user a snippet of information related specifically to the thing they’re looking at has been around for a long time. It was 1987 when IBM introduced the  Common User Access standard, which defined standards for computer program user interfaces. That standard included a specification that contextual help be accessed using the F1 key, which many programs were already doing before the standard was even introduced.

Back then the definition of “context” was limited to “the place where the user is in the program.” For example, if the user is on the Name field and presses F1, the Name field contextual help appears. Some users might see a translated version of the help, if they were using a translated version of the UI, but by and large the field you were on was the only thing that determined which piece of field help you saw.

But these days, the name of the game is social integration. Have you noticed how many programs let you log in with your social credentials? That’s convenient for you, the user, but it also lets those programs have access to the information in your social media presence. That might sound a little scary, but if users are willing to give your system the access to information about then, there’s no excuse for that software not to leverage what it knows to create an exceptional help experience.

When my writers weren’t sure of what to write in the contextual help system, I’d tell them to think about what they’d say to the user if they were sitting right there, running into trouble at that spot. Of course, if each software license came with a friendly, patient person sitting next to you, ready to guide you over stumbling blocks, you’d expect that person to get to know you and use that knowledge to target the message.

As technology gets access to more and more of this kind of knowledge, suddenly which field you are on does not need to be the only deciding factor in which piece of help the system shows you.  This knowledge of the user becomes a dimension of context, helping to pinpoint exactly the right piece of content for this one, special person.

Here are three potential dimensions of context that you might want to consider as you go forward designing an excellent user assistance experience:

Dimension #1 – Experience Level

Whenever I’m thinking about a piece of information about a user as a dimension of context, I ask myself two questions about it. The first is:

How does this user attribute affect how I would help them?

So, in this case, if you were sitting down next to a person, how would their level of experience affect how you’d help them?

Probably a brand new user would need some more background information than a person who already had the hang of the application, but that’s about it. I would not, for example, expect to see a different piece of help for someone who has been using your product for one year versus someone who had been using it for two years. You’re either new or you’re not.

The second question is:

How can we capture this information?

It doesn’t do much good to prepare a separate piece of field help for a first-time user if your software can’t tell who your first time users are. Identifying first time users is pretty easy for online applications where users log in since you can just count the number of log-ins. It’s more complicated for desktop applications, since people can share the application and you can’t tell if the person  using it today is the same person who’s been using it all month or someone completely new.

But that’s not a reason to give up. You can still create that first time user experience and show it the first time the application is opened, plus make it available to launch again.

Dimension #2 – Job Role

If you’re document enterprise software that people are using to do their jobs, does the job role affect what you would tell the user in the contextual user assistance?

I can imagine a piece of business software where front-line users need to know the nuts-and-bolts of using the feature effectively, but a manager needs to do reviews, while a developer needs to automate processes. The help for the same field for these three different job roles would be different:

• Front-line user – What to put in this field
• Manager – How the value in this field affects the rest of the workflow
• Developer – How to access the value in this field via the API

So now that we’ve determined that there could be different content based on job role, we need to ask whether we can capture this attribute.  In business software, it is not uncommon to have system permissions based on job roles. If that is the case in your product, you could leverage those permission settings to determine which help a person sees.

Dimension #3 – Industry

If your product is used by people in a finite number of discrete industries, would the user’s industry affect what you would say to them?

Let’s take as an example a payroll software package that is used primarily by accounting firms and corporate human resources departments. For the same field, you might take some accounting jargon for granted in the field help when talking to the accounting firm, but define the accounting terms a little more for the human resources user.

So, yes, in this case, the industry would affect how you tell the story of the software. But how can we know what industry a user is in? That’s a tricky one because there’s so much variation in how industries are defined: the same company might be identified in different industries by different people. So, why not go straight to the source and ask the user? You could set up a profile page where the user could indicate their own industry.

The Interplay of Context Dimensions

I’ve been calling these user attributes “dimensions of context” because they don’t just control the selection of content on their own, but actually work together. For example, how would the contextual help you write for a manager who is a first-time user in HR differ from the help you would write for an experienced manager in HR? And how would that differ from a developer first-time user at an accounting firm? To make matters more complicated, you might not have a different answer for every combination of user attributes.

What to hear more?

Traditionally in technical communication we have had to write for the least-common-demoninator user. This change in paradigm to a personalized user assistance experience means great things for the field of technical communication:

• By writing a separate experience for each user, the burden on each user to find relevant information is less, making for happier customers.
• This approach requires deep knowledge of the users and the subject matter plus advanced tools, which are special skills you bring to the table, not commodities.
• Creating highly integrated, highly contextual content brings you more tightly into the development process, giving you the opportunity to demonstrate greater worth to your company.

The data management and content strategy needed to support this kind of solution can get kind of complicated, though. It demands changes to your tools, processes, and general thought process about providing user assistance. There aren’t a lot of best practices already in place to guide you.

Even so, I predict that this sort of customized interaction will become a requirement of technical communications departments going forward.

Amanda Cross is a guest writer for MindTouch Magazine, she has over 10 years designing cutting edge technical information processes and is the owner of Crosswise Consulting.