Test driven development and usability testing

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 , 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.

  1. How Test-Driven Development Increases Overall Usability
    Programmers are People, Too (thanks to Iikku for this) []
  2. 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. []

 

The temptation to avoid usability work

At Fluxitek, I am involved not only in the design of the overall user experience, but also in implementation. The temptation to skip work is sometimes great for our team, and I too have to keep convincing myself why usability work is absolutely crucial to product success. Trying to find a succint enough way to express the basic needs for the work…

Software engineers often question the value of usability work. It may be that a good designer could design a UI that does not create major confusion for most – if those designers already have lots of experience from usability testing in other projects.

However, in any application that is done without explicit user research and usability testing targeted for the specific UI, you tend to have dozens of small confusing moments that make up the overall user experience and lead to a general ‘yuk’ reaction. Not to mention that if you don’t intimately know your users’ goals, you are likely to be designing the wrong overall application.