Robert Martin spoke charismatically about test driven development in RailsConf in 2009.
He promotes the idea of having automated tests (unit tests) and running them all the time to prevent your code from becoming an enormous, unholy mess. When you have tests, you are not afraid of making changes. (In fact, you are effectively improving the user experience of programming1.) You can play all you want, because you know exactly when anything in your code breaks as a result of you changing the code.
Guess what? It applies to #usability, too. Three points:
What is a test? Essentially, it embodies what *should* happen. If, after having changed your code, that something doesn’t happen, you know you are in trouble.
Likewise, When you test usability, you expect the person looking at your UI to do something. When they don’t, you know you have two options: go back to the original, or make it better.
Debugging. When you test code, you may spot that oh, there is an error: the test didn’t pass. Ideally, debugging is so built into the process that you don’t really think of it as separate: since you have tests for every little part of the program, the bug may be pretty easy to spot.
When you usability test, when you notice an issue (and try to keep your calm so the test participant does not notice your frustration) and if your test participant is talking out loud like you have told them to, you learn the reason there and then, and the solution is often more or less obvious.
Lastly, tests are not something that lead to great design. Your code may still suck, but at least you have the courage to improve it since you can test whether your new fix breaks anything else. The important thing is that the tests exist so you can rely on them.
The same thing with usability. A test does not do anything for the design in itself. If you have failed to understand the user’s goals in the first place, a usability test will only show you how the user gets confused while doing the wrong thing in the first place, or while doing it in an unrealistic setting2.
However, a test does describe what the UI was designed to do. When you have comprehensive usability tests for a UI, you can use those test tasks against any new version of the UI, and see if it still serves the purpose it was originally created for, and how well.
In ways, usability testing is just like unit testing: When you have tests defined and you regularly run them alongside development, you know your stuff is good.
If you don’t run them, you don’t know. More likely than not, what you create just does not hold together.
- How Test-Driven Development Increases Overall Usability
Programmers are People, Too (thanks to Iikku for this) [↩] - For example, Richard E. Cordes discusses having tasks that fit actual user needs in Task-Selection Bias: A Case for User-Defined Tasks. But the most important thing is to get started with the tasks that are more or less obviously the UI’s purpose. [↩]
