When you bought software, you used to always have a tome called the “User Manual” that accompanied it and would either have to plod your way through parts of that tome in order to figure out even the most basic functionality of the software or you would curse and growl as you guessed at how to make it do what you wanted.

Even as a content developer, I don’t miss those days.

Now I see a large trend to writing more intuitive software, software that doesn’t need a tome just to get started. This is a good thing, in general.

But I also see a move toward not providing any documentation in the belief that the software is so simple, it’s not needed.

In some cases, I think this is okay, especially for entertainment or game software. The potential cost is usually very minor – like the user losing a game or being offered a recommendation that doesn’t suit the user. But in cases where the software is business-related and has the potential of real-world costs associated with incorrect usage, I think this can be a mistake.

There are a couple of reasons why I believe this:

  • I would want to be sure that I entered or set up the software correctly so I know the software has the right inputs from which to base its actions. It’s difficult to tell this without any documentation.
  • I would want to know how the software is making decisions or why it is taking actions. Especially in the case of money-impacting transactions, I wouldn’t trust that the magic happening behind the curtain is the right magic unless I had the ability to understand what it is, even if the formulas or algorithms are proprietary. Without any documentation, this remains PFM (Pure Fricking Magic).
  • What is “simple” to one person is not necessarily simple to another. There may be cases where something that is obvious to someone used to the software is not to me and I need a way to get more information if I need it.

There is usually a place for a getting started document, at the very least. After that, it pays to consult the actual users of the software. Do they want a comprehensive user manual? Do they want multi-media content? What are they looking for? What do they need when new features come out? What are their preferences?

It doesn’t have to be a tome, though. There are often small pieces of documentation that can be provided to the user that they can opt to read that will help them better understand what the software requires, what the software does and why. These can play a part in giving the users confidence in the software as well as provides the information required if they want to double-check the software. Sometimes a short video can make all the difference to users.

But, like the movement to simpler software, I do advocate that content should be simple and as easy to understand as possible. There’s no need to use huge words when plainer language will do. There’s no need to have huge, long explanations if you can create a simpler way to convey the same information. Content should only be as complex as it needs to be in order to provide the value it needs to.

In some cases both the engineering and content teams need to step back and ask themselves not just whether the software NEEDS documentation but whether some users would WANT documentation.