Usability, testing and documentation

The three disciplines of usability, testing and documentation are important to the success of hi-tech products. Particularly with software products, these areas are often overlooked, cut short, left to the last minute or delegated to junior members of staff. However, these three areas have a profound affect on the end user's experience of a software product. As customers become more perceptive about IT, their expectations become higher. Since customers now have more choice than ever, to be successful, a software product needs to stand out from the crowd. This article explains why the three disciplines are important to the overall success of a software solution. It concludes with recommendations for obtaining the best return on investment.

Common aspects

All three disciplines provide the connection between a product and the people who use it. All three disciplines directly influence the quality of real-life use:

Usability makes the product as easy as possible for the users. If the usability is poor, important tasks can be frustratingly difficult, and complex tasks can become impossible. Good design reduces documentation requirements.
Testing ensures that the product works according to the design. If the software testing is poor, bugs get in the way of a user's work or pleasure.
Documentation tells users how to use the product. If the documentation is poor or non-existent, customers find the products confusing or difficult to learn, and they fail to discover important features.

So why are these professional fields so often undervalued? One theory is that while these disciplines contribute greatly to the user experience, they do so after a user has completed the sales process. With typical off-the-shelf products, users can't judge the quality of the manuals or online help, the robustness of the product, or how easy it is to use until after they have parted with their cash. Thus, short-sighted organisations focusing on sales will put a priority on design, engineering, sales, and marketing. Writing, testing, and usability are not seen as so important (in sales jargon, they are satisfiers, not motivators).

This is short-sighted, because without the contribution of the three disciplines to the user's satisfaction, sales will suffer, repeat business will be undermined, and customer support will become expensive. Moreover, on the Internet, customers can often judge these items well before they decide to spend their money (which rather contradicts the theory presented in the previous paragraph!).

The three disciplines can be seen as differentiators rather than as satisfiers. If you build a product that is the only product in its field, it doesn't really matter what the level of documentation is or how usable the product is. If people need the software, they will learn to use it. However, those types of products and solutions are rare these days. More often, products exist in competition with others. Therefore, apart from time to market and the brand, the differentiators between products are the perceived level of quality, the documentation and the ease of use of the product.

Added value of each discipline

In this section, we each summarise why our own discipline adds the most value to a software project. Of course, the reality is that no one discipline is of primary importance—it really is true that the whole is more than the sum of the parts.

Usability

A product can have top-notch documentation and a bug-free implementation, but if it doesn't give users what they want, or if it doesn't work as they expect, the product will sit and gather dust. In short, user research provides the strongest bond between the people who create a product and the people who use it.

The following example is from a web-based software application that is provided by one of the UK's largest public-sector organisations.

Dialog box

Read the text. What do you expect to see on the dialogue box? That's right, two buttons; 'Cancel' and 'Save'. So, where are they? As it happens, the two buttons are elsewhere on the user interface. The dialogue box is just a reminder about the options available. From a user's perspective, the interface is not clear at all. Why aren't the buttons on the popup?

This is not an isolated example. Most people know of software applications that are just as confusing as the example above.

Testing

Many of the projects that Bill (the tester) works on contain very little documentation. Most of that is written by the developers or the test team. Usability is also very low on the agenda, and is often left to the testers to give their opinion. This doesn't stop a product or solution being adopted. Developers and designers, while not perfect, have a better understanding of usability than they used to, and solutions are becoming more 'user-friendly'.

End-users are adaptable and eventually they learn to use even the most complex systems. Documentation and usability may increase the speed at which they can complete their work, so there is business benefit to these.

End users don't care if a solution hasn't been tested, but they do care if the solution is not robust or if the results are not accurate. If the integrity of a solution is not guaranteed, the solution will not survive in the marketplace. Additionally, there are also the legal aspects of software to consider. It's not just the developers who make mistakes. Designers and business analysts also make mistakes, and when they do, the mistakes tend to be more expensive to resolve. Testing is partly about finding faults. It is also about risk mitigation, with identification of faults almost as a by-product. This shift is due to two main factors. Firstly, the time to market is critical, and secondly, software is so much more complex than it was back in the early years.

Of course, testing itself is not infallible, but generally, no one thinks to test the testers.

Documentation

Users may have exactly the functionality that they want, and the interface design may be clear (so, usability has done its job). The software may be error free (so testing has done its job).

Much software is incredibly complex, and therefore, users need instructions, because using software is not self-evident. Here, we are not referring to low-level interactions such as entering values in fields or clicking buttons. That kind of interaction should generally not be included in a user guide. (Certainly, some people don't know that information, but they need training on basic techniques, which is not the function of user documentation.) People need guidance on the business tasks that they perform. They need to know the workflow, otherwise they will flounder.

On the other hand, it's easy to fall into the trap of providing comprehensive documentation that doesn't fulfil a real need. If people don't have problems with aspects of a software product, why does that aspect need to be documented to the same level as some complex area? For example, your software might contain a calculator on some utility screen. Do you need to explain how to use it? Quite possibly not: it's not an essential part of the product. Or, there may be a set of input screens that capture customer information. In an ideal world, the data entry fields should be self-evident. So, all you need to do is tell people to enter the data. You don't need, "Enter the customer's name in the 'Customer Name' field".

Of course, that approach does lead to inconsistency. Some aspects of the software product are documented in more detail than other aspects. My opinion is that that is not an issue. I'm very much in favour of documenting the exceptions—the things that cause people problems, not the things that are self-evident to most users.

Where should you spend your money?

Every project has limited resources, so, where should you spend precious resources to gain maximum return on investment?

Firstly, ensure that your design is good. It should be intuitive, follow conventions, and allow users to perform business workflows with ease.

Secondly, test the product. Ensure that it works correctly.

Lastly, spend money on documentation. A well-designed product can greatly reduce the amount of documentation that you need. Conversely, no amount of documentation will make up for a bad design.

Publication information

This article was written by Mike Unwalla, with significant contributions from Andrew Swartz, Managing Consultant, Serco Usability Services (www.serco.com/usability) and Bill Matthews, Principal Test Analyst, Target Testing Ltd (www.targettesting.co.uk).

Publication history:

Usability, testing and documentation, BUG Magazine, March/April 2006 (www.richplum.co.uk)

This web page created 2006/04/26

The three disciplines, ITNOW, January 2007 (www.bcs.org/itnowextra)

The three disciplines, EngineerIT Online, February 2007 (www.eepublishers.co.za/view.php?sid=7921)

RSS feed