A project I worked on recently brought up an interesting communication problem: how to supply help with using software, when the main thing getting in the way is the lack of domain knowledge.

The problem

The product in question is ANTS Memory Profiler, an application for profiling memory usage in .NET applications.

Here's the sort of thing we saw in user tests, repeatedly:

1. Install and run software. Absolutely no problems here.
2. Choose an application to profile. Again, no problems with this.
3. Display and filter results, and then start to look at results. User comments like:

"Wow that's cool! I really don't know what I'm looking at, though"

"I have no idea what a large object heap would be used for"

" I can see what it's showing me, but does that indicate there's a problem?"

So, there wasn't a problem with using the software insofar as people could get it up and running, and navigate around it successfully. The difficulty came when they tried to apply the software to their problem:

• We showed them data that they couldn't relate to their knowledge of memory (e.g. the "large object heap")
• We gave them access to a lot of data about memory usage, but they needed an understanding of what "good" or "bad" memory usage might look like, so they could apply the data to their problem.

What was missing was domain knowledge. The tool shows users data about their application, but they need domain knowledge to understand how to interpret the data and use it to diagnose memory problems.

How to deal with domain-knowledge gaps

When we first discovered this, I searched around the usual tech comms resources, to find out what people recommended about filling in users' domain knowledge. The general conclusion was: "don't!" Wise advice generally, for various reasons...but in this case, it's not really an option. Potential customers download a trial version of the software to decide whether to purchase: and if they can't apply the software to their problem, we've missed an opportunity to impress them.

So, we had to find some way to address the domain knowledge problem. At the same time, we couldn't just give people a document to read, with all the background information they need on it - it was quite clear that there would be no hope of them reading it.

The learning process

We approached the problem by looking at what learning users would be willing to do, and when. Here's the learning process we think users were going through:

1. How do I make this software profile my application?
2. What am I looking at?
3. What should I look for?
4. Why should I look for that? What does that tell me about my application's memory usage?

The design approach

As described in an article I wrote somewhere else, the user-assistance design approach we take at Red Gate is to use layers of user assistance, from the words visible in the UI out to links to 3rd-party content. This model looks a bit like this:

Help design approach: starting from the UI and extending out to 3rd-party materials

What this looks like in practice

Combining the learning process we identified, and this design approach, the solution we came up with looks a bit like this:

1. How do I make this software profile my application?

The following screenshot shows the ANTS Memory Profiler start-up screen, with the "help" mechanisms that support the user with profiling their application.

Screenshot: ANTS Memory Profiler start-up screen

2. What am I looking at?

The following shows part of detail of data display, including the help mechanisms that support understanding of what's showing on the screen

Screenshot: help mechanisms to support understanding what's on display

3. What should I look for?

The following screenshots show the help mechanisms with recommendations designed to support users with working out what to look for in the data displays. Often, these recommendations are combined with the help that explains what's currently on the screen.

(Note that in the previous screenshot, the "Start here" box in the screenshot above also tells the user what to look for, as well as explaining what they're looking at.)

Screenshot: ANTS Memory Profiler full screen, showing recommendations in help

Screenshot: detail of column-header tooltip combining information about what's on display with recommendation about what to look for

Screenshot: product-level embedded ua, with link to web help

Screenshot: web help topic with information about what to look for in the data

4. Why should I look for that? What does that tell me about my application's memory usage?

Some of the information needed here is contained in the help described above, but generally this level of explanation is too complex for most of the help mechanisms. As well as some strategy recommendations in the web help which are designed to guide the user in the main use-cases, the help contains links to 3rd-party tutorials on .NET memory management, and case-studies and videos that show the product in action in different contexts, and include an explanation of strategy.

Screenshot: web help topic (landing page from link in embedded ua) with links to other resources

Has this been successful?

It's too early to tell. We've seen all the content being used frequently in user tests or with data from Google Analytics, so we've definitely identified some of things people want to know about, and put content in the places they expect it. The product hasn't been out there long enough yet to understand whether we've managed to fully support the users' information needs, though. We'll be monitoring closely, and listening to all the feedback we get.