Frequently, with software products, usability, testing, and documentation are ignored, are not continued, or are done by junior employees. However, these three disciplines have a large effect on a user's experience of a software product. Customers now have more options than before, and their expectations are high. This article explains why the three disciplines are important to the success of a software product, and how to get the best return on investment.
All three disciplines supply the connection between a product and the people who use the product:
- Usability makes the product as easy as possible for the users. If the usability is bad, important tasks can be difficult, and complex tasks cannot be done. Good design decreases documentation requirements.
- Testing makes sure that the product conforms to the design. If the software testing is not satisfactory, errors prevent users from doing their tasks.
- Documentation tells users how to use the product. If the documentation is bad, or if there is no documentation, customers can become confused, and they do not learn about important features.
Why are these professional disciplines not given importance? According to one theory, these disciplines improve the user experience only after a user has completed the sales process. With many off-the-shelf products, users cannot evaluate the following things until after they have spent their money:
Organizations that think about only sales put an emphasis on design, engineering, sales, and marketing. Usability, testing, and documentation are not given importance. This is not wise, because without the benefit of the three disciplines to make the product satisfactory to the user, sales will suffer, repeat business will be lost, and customer support will become expensive. Additionally, on the Internet, customers can frequently evaluate software before they decide to spend their money.
If a product has no alternatives in the market, the level of documentation and the usability of the product are not specially important. If people need the software, they will learn to use it. However, this type of product is unusual now. Usually, a product has many competitors. Therefore, for buyers, except for the brand, the important differences between products are the apparent level of quality, the documentation, and the usability.
In this section, we each show why our particular discipline adds the most value to a software product. Clearly, no discipline is of primary importance, and 'the whole is more than the sum of the parts'.
A product can have correct performance and excellent documentation, but if the product does not give users what they want, or if the product does not operate as users expect, people will not use the product. User research supplies the strongest connection between the people who create a product and the people who use the product.
The following message is from web-based software that is supplied by one of the UK's largest public-sector organizations.
Most people expect to see two buttons on the message: 'Cancel' and 'Save'. The two buttons exist, but they are in a different location on the user interface. First, a user must click 'Confirm'. Then, the user must find the other buttons, and click one button. A better option is to put 'Cancel' and 'Save' on the message, not in a different location on the user interface.
Many people can give examples of software that is as unclear as the previous example.
Many of the projects that Bill (the tester) works on do not contain much documentation. Most of the documentation is written by the software developers or by the test team. Usability is not given primary importance, and usually, only the testers give their opinion about usability. However, the products are successful in the market. Although software developers sometimes make mistakes, they have a better knowledge of usability than they did in the past, and products are becoming more usable.
Users adapt, and with time, they can learn to use complex systems. Documentation and usability can increase the speed at which users complete their work. Therefore, there is a business benefit to documentation and to usability.
Users are not worried if software is not tested, but they are worried if the software is not reliable or if the results are not accurate. If the software does not operate correctly, then the software will not be successful in the market. Additionally, conformity with the legal requirements for the software is important.
Not only do the software developers make mistakes. Business analysts also make mistakes, and when they do, the mistakes are usually expensive to correct. Testing is partly about finding errors. Testing is also about risk mitigation, with the identification of errors almost as a secondary effect. The emphasis on risk mitigation has two primary causes. First, the time to market is important. Second, software is much more complex than it was in the past.
Clearly, testing is not without error, but usually, no one thinks to test the testers.
Although usability and testing help to make software easy to use, much software is very complex. Without instructions, people cannot use the software correctly. People need to know their business tasks and the workflow, or they will struggle.
However, do not supply detailed documentation that does not meet a real need. Sometimes, documentation contains too much information. For example, low-level operations such as how to enter a value in a field or how to click a button are not necessary for most people. People who do not know that information need basic IT training, which is not the function of user documentation.
If people do not have problems with parts of a software product, those parts do not need to be documented to the same level as other parts. Two examples follow:
- Software contains a calculator on a utility screen. Possibly, documentation does not need to explain how to use the calculator, because the calculator is not an important part of the product.
- Customers enter personal information on a screen. If the data entry fields are clear, you need only to tell people to enter the data. In the documentation, do not specify each data entry field. Do not write, "Enter your name in the 'Your Name' field."
That strategy causes some parts of a software product to be documented in more detail than other parts. In my opinion, for a user guide, different features of the software do not need equally detailed documentation. Tell people about the things that cause them problems, not about the things that are clear to them. (For a reference manual, document all parts of the software.)
To get the maximum return on investment, we recommend the following steps in order of importance:
- Make sure that the design is good, simple, conforms to standards, and lets users do business tasks easily. Sometimes, a small change causes a large difference. For example, see 'How changing a button increased a site's annual revenues by $300 million' (www.uie.com/articles/three_hund_million_button).
- Test the product. Make sure that the product works correctly.
- Develop the documentation. A well-designed product decreases the quantity of documentation that is necessary. However, documentation cannot correct a bad design.
This article was written by Mike Unwalla, with much input from Andrew Swartz, Managing Consultant, Serco Usability Services (www.serco.com/experiencelab/) and Bill Matthews, Principal Test Analyst, Target Testing Ltd (www.targettesting.co.uk).
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