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…coupled with the user’s determination to plough on regardless of this gap in their knowledge.
The product in question is a software application for profiling memory usage in .NET applications.
Here’s the sort of thing we saw in user tests, repeatedly:
- Install and run software. Absolutely no problems here.
- Choose an application to profile. Again, no problems with this.
- 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.
So, 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, maybe…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, not many are going to be impressed enough by the software to decide to purchase it.
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:
- How do I make this software profile my application?
- What am I looking at?
- What should I look for?
- 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 at this company was 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:
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.
2. What am I looking at?
The following shows part of the detail of data display, including the help mechanisms that support understanding of what’s showing on the screen
3. What should I look for?
The following screenshots show the help mechanisms with recommendations designed to support users work 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.)
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, designed to guide the user in the main use-cases, the help links to 3rd-party help about .NET memory management and case studies and videos that show the product in action in different contexts, and include an explanation of strategy.
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 the 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…
About the author
Rachel is our Lead Consultant, advising customers on documentation strategy, and helping our growing team of technical writers to develop their skills and hone their insights. She is a Member of the Institute of Scientific and Technical Communicators and also contributes to the ISTC’s award-winning journal.
Please rate this article
Originally published August 2009