Posted by: communicationcloud | August 22, 2009

3 good reasons software will always need help

When I’m designing a set of help information, I do a lot of work on getting the information that people need while they’re using our software into the user interface – as tooltips, pop-ups, static text – instead of sending them to a separate help system. At Red Gate, we call this way of delivering information “embedded user assistance” (embedded ua for short).

A really interesting question came up about this the other day:

If we get the user interface and the embedded ua right, does that mean we won’t need web help any more?

My answer? A definite “no”.

With the memory profiler project I described in a previous post we actually set out with pretty much this goal in mind: put all the help in the user interface apart from a couple of videos to get people going. But it rapidly became apparent that this was not going to work for this product … and I believe that for similar reasons that’s always going to be the case, apart from a few exceptions where the use-case is really fixed or specific (e.g. custom software for customer service).

A note before I get going: when I talk about help here, I’m referring to web help because that’s what we use at Red Gate; but it applies equally to other types of help such as print formats, CHM, PDF or other pages that open outside the environment of the software’s user interface (including pages with video in them).

1. People need to understand how the software fits into their context of use.

It’s very rare for software to be only used in one specific context and installation environment. As soon as these variables get added to the context of use, it stops being possible to give people all the information they need in a small space.
The software can anticipate some of these variable – e.g. by detecting what version of some other component is installed, and changing the embedded ua content to reflect this – but other elements, such as architectural factors, are less easy to detect and need the user to make the decisions about how this affects the way the software is configured or used.

2. People don’t just need to understand what to do or how to do something, they also need to understand why to do it.
Embedded ua is really great for giving people hints on what to do on a particular screen and how to get the behaviour they want from the software. But when you want to help people understand why they might choose one option over another, or how to decide whether to run the software in Mode A or Mode B, you need more than embedded ua.

3. People need to understand the end-to-end process of using the software, not just the bit-by-bit view.

A well-designed user-interface goes a long way towards solving this problem, but with many products there’s still the need for a bit more to help new users fit the product to their mental model of what they’re trying to achieve.

A few not-so-good reasons embedded ua will never be enough on its own

I’ve cheated a bit here. These are actually pretty good reasons … just not as good as the ones above, and a little more care needs to be taken with citing them as reasons for having help outside the software’s user interface:

  • Help is often part of purchase decisions – either implicitly (as part of a potential customer’s judgement of the quality of a product) or explicitly (as part of a purchasing checklist). Some people even like to read the help as a way of understanding whether the software does what they need.
  • Embedded ua relies on people who learn by starting the software and exploring. This doesn’t suit everyone’s learning preferences: some people always like to read something before they’ll use a product. (When this is the case, it’s a really good reason for not relying on embedded ua alone; the reason it’s in the not-so-good list is that this learning preference not be equally represented in all bodies of users – e.g. there may be cultural differences – so you need to understand your user base before using this as a reason for having help.)
  • Help – particularly web help – gives you the flexibility to add to the information available to users, without requiring a software upgrade. There are always things that you won’t discover are problems until after a software release, even with the most rigorous research process (e.g. new 3rd party technologies or new steps being added to your users’ everyday workflow). This is in the not-so-good list because in an ideal world, if embedded ua is the best way to deliver information, then it should be possible to update the embedded ua without requiring a new software release. To an extent this is possible already, but not for all types of embedded ua (at least, I haven’t seen an example of it working like that yet).

So there you have it: the reasons I firmly believe that there will always be a need for help. I’m sure my list isn’t exhaustive though. What have I missed?



  1. […] it can be used to help people do their jobs. In a recent blog article Rachel Potts has explained why software will always need help, and I agree with the points she makes. Software manufacturers who don’t provide the […]

  2. Very good points Rachel. I have mentioned this post in my latest blog article.

  3. I agree. Embedded UA solves one type of problem. Web help solves another. Most software requires both.

  4. Couldn’t agree more. This discussion has highlighted the fact that until we can get a computer to think like a human (heaven forbid) there will always be a need for user assistance. Trouble is one human often thinks differently to another and that is the real challenge for a user interface and it’s accompanying documentation.

  5. Totally agree; there will always be a need for help to supplement embedded UA. If I may add to Rachel’s ever-so-good list of not-so-good reasons, another scenario is when there is simply no UI in which to embed UA yet. This is often the case with (pre-)installation info: You can embed UA in some software installers, but basic info such as system requirements still needs to be made available outside the UI; as webhelp, manual, or whatever else one prefers.

  6. […] Three good reasons why software will always need help […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: