Creative Commons

November 19th, 2010

I am currently working on a private software project in a startup. I am involved not only in the design of the overall user experience, but also in implementation, since we are not many. The temptation to skip usability work is great for our team of two, 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.

April 9th, 2010

Robert Martin spoke charismatically about test driven development in last year’s RailsConf. This totally saved my day today.

Why? Because the guy promotes the idea of having tests and running them all the time to prevent your code from becoming an enormous, unholy mess. Because 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.