The Future of Usability Testing

Written By: Peter Abrahams
Published:
Content Copyright © 2008 Bloor. All Rights Reserved.

I recently chaired a round table on the Future of Usability Testing. It was sponsored by Techsmith who supply the Usability Testing Tool Morae (see my earlier article).

The invited attendees included developers, usability experts, an internet psychologist, and journalists all with considerably understanding and strong opinions about usability. I came with a strong interest in accessibility, which to a great extent can be seen as a subset of the usability requirements.

The aim of the roundtable was to better understand how to make usability design and testing business as usual in IT systems. This big question was approached by looking at several more specific questions:

  • Why is usability important?
  • What are the barriers to usability design and testing?
  • How should it be imbedded into all phases of development?

Importance
Usability is important because:

  • It drives down production costs. There should be fewer calls to the help desk for assistance in using the system. Customers will complete more transactions without having to turn to call centre staff to process the transaction for them. Internal users will complete tasks faster and more accurately, so increasing their efficiency.
  • It improves sales. If a system is easy to use a customer is more likely to complete a transaction, so increasing conversion rates. If it is too hard the user will turn to another supplier, with the short-term loss of this sale and the probability of the long-term loss of future sales.
  • It enhances brand loyalty. If a system is easy to use then the client should be delighted by the experience. This will add to their positive feelings about the quality of the brand. This is becoming more important as users are being exposed to best-of-breed systems which shows what is possible.
  • In the public sector it provides access for all. Government bodies have an obligation to provide services to all members of the community; this should be true of the private sector as well but in reality they can decide not to service some groups. A system that is usable and accessible will reach a very large percentage of the population.

Barriers
Usability design and testing is not imbedded into the development cycle because:

  • The benefits of good usability are not recognised by commissioners of the system. Advocates of usability in IT systems have not been sufficiently vocal. It is assumed that systems will be usable by default. This is in contrast to the effort that is put into the usability of the physical environment such as shop layouts or car design.
  • The concepts of usability are not understood by the IT industry. Usability has not been a key part of IT education. IT developers are experts in IT and the technology and do not understand the difficulty many users have.
  • The cost and benefits are not visible until a system is in production. When problems are discovered the best solutions may not be obvious and the cost of remedial action may be considered too high, so the system remains less usable than it should be.
  • Extra design and testing seen as a cost. Development is driven by budgets and deadlines; if usability is not included explicitly in the requirements then any usability improvements that could lead to overruns will be shelved until a version 2 fix cycle.

Imbedding
Usability is often only considered during the final user acceptance phase. Usability design needs to be imbedded throughout the development process. The following are thoughts on achieving this:

  • ISO has a set of standards on usability. The concepts in the standards should be included in the development processes.
  • Educate, educate, educate. Usability design should not only be an essential part of IT education but should also be covered in MBA courses so that all stakeholders understand the benefits.
  • Use examples to show the benefits. Show all the stakeholders examples of good and bad usability to ensure buy-in by the whole team. The most effective examples may come from running usability tests against existing systems that the stakeholders are familiar with.
  • Gather usability requirements at the beginning of the project and include them in any requirements’ definition.
  • Include usability testing at the ‘paper’ prototype phase and all subsequent phases. Usability is not just about the screen design it is about the complete process flow.
  • Include usability experts on the team. The experts should be used to ensure that all aspects of usability are covered and that common pitfalls are avoided; however responsibility for usability must remain with the whole team.
  • Provide tools for managing, running and reporting on usability tests. Automated test tools should be included; they can highlight bad coding that can impact usability. However, the main tools must enable usability testing with real users.
  • The results of usability testing must be presented to all the interested parties. A usability issue may be alleviated by a simple change to the screen design but it may point to a more basic problem that can be resolved by a change in the process. A process change needs the business to be involved and not just IT.
  • The usability test reports must be usable. The reports must be organised so that they are understandable and usable by all the stakeholders.
  • Usability design and testing must continue into production. Analysis of usage patterns, feedback from live users and further usability test on the live system may identify new usability issues. The new issues may be caused by changes in usage, changes in user population, addition of new functions, and maintenance of existing functions, none of which could have been picked up during the development phase testing.

The inclusion of usability design and testing into the development cycle need not be difficult and will enhance the user experience and the overall benefit of the solution.