Usability Testing buyers guide

All applications have users, and as much as engineers make jokes about “problem exists between keyboard and chair”, they’re an important part of the development process. Applications need to be designed to be easy to use, and usability needs to be considered at all times, right from the very start of the development process and beyond, even as an application transitions from development to operations.

It can be hard for developers to appreciate the need to design for usability. There’s little contact with end users, and often little guidance on what needs to be done to ensure a good user experience. Often conflated with accessibility, usability is as much a mix of psychology and design as it is a development methodology. Usability isn’t about dropping controls on a page or a form; it’s about understanding how an application fits in with a user’s workflow so it doesn’t jar or distract, but instead makes sure that users remain productive.

Perhaps the biggest problem facing a development team wanting to implement usability tests is that usability is a non-functional requirement. You can’t define usability in terms of application inputs and outputs, and it’s not something that can be handled by automated tests (though you can use automated tools to test for the closely-related accessibility). While it is possible to test for usability as part of the development workflow, by making users part of your development team and having them interact with prototypes and with non-functional builds, it’s something that’s more likely to be part of your overall acceptance tests and part of any operationalisation process – and possibly even as part of a marketing exercise for external facing applications or Web sites.