User inclusion is essential in user-centered development. It is the only way to understand the requirements users actually have and where problems could arise when interacting with products. This principle is firmly anchored in DIN EN ISO 9241. Usability testing is therefore necessary in software development, to identify an application’s real usability problems.
But, as anyone who has already run usability tests knows, they take time for preparation, running and evaluation. Intrinsically this is not a problem, but it’s a little more difficult in the context of agile software development.
Challenges of agile software development projects
Agile software development projects are divided into short development periods within which user stories are designed, implemented and tested. This might mean that a release-ready product could be required after as little as two weeks. This poses a major challenge for usability engineering, because it means that within those two weeks requirements have to be defined, and prototypes implemented and tested, if usability engineering is to be implemented correctly. This implies that methods must be able to be carried out as quickly as possible without loss of quality.
There is potential for optimization in usability testing. Usability tests are supposed to be performed with three–five users per user group. In a complex application where, for example, seven user groups are identified, it would mean that we would have to run 35 user tests in two weeks. As other activities in the process are far from negligible, this would be impossible.
The RITE method
We have had positive experience with the RITE (Rapid Iterative Testing and Evaluation) method. Using this method an application is tested with users for only as long as a specific number of important usability problems can be identified. This can for example be the case after only two users. Any problems are elaborated, and suggestions for improvement developed and implemented directly in the application. The remaining tests are then carried out with the improved version. This has the advantage of less time being required for testing and quicker reaction to any identified issues. It implies that the application is subject to a process of continuous improvement. However this is not all that is required for optimization of usability testing.
Time saved during the evaluation process
Time can also be saved during evaluation. Classic waterfall projects are often well documented, resulting in longer test reports being sent to the customer. These take a long time to create, which is usually not available. In addition, as management does not want to spend time reading reports, the whole thing is usually associated with a presentation.
We now intend to invite our customers to be part of a usability test, so that we can observe the test in a separate room, either behind a mirror or by video transmission. Ideally both developers and management representatives are present. While a usability engineer performs an experiment with a test subject, a second engineer can moderate from another room. It has proved useful to hang all the screens that the user comes into contact with during the test on partition walls. By means of Post-Its, the persons in the next room can then record all usability problems and take notes on the screens.
This approach has advantages, as the people responsible for developing the application can see where problems occur directly. On one hand this creates greater acceptance for usability engineering, while on the other problems need not be described and presented in detail, as participants themselves can remember them. The resulting documentation can therefore be more streamlined.
Potential problems
There are problems with this approach, however – chiefly that participants do not always know which problems are actually usability problems. For example, if a user says during the "Think Aloud"-method that they could not find something quickly, this is often recorded as usability problem. However, the user might have only needed three seconds to find the item, which corresponds to a reasonable time: this is not necessarily a usability problem. Opinions can also diverge over the severity of problems and their resulting prioritization.
Give it a try!
It’s very important to train developers and other project participants in advance, to teach them what they should look out for. This is particularly useful when working with the same people in a project over a longer period, as it allows a well-established team to emerge over time.
Give it a try! It's worth it!
Comments