Usability testing turns a good product into a great product.
We did some formal usability testing in the early days of Feature Upvote. This turned out to be one of the most valuable things we did in our early days.
In this video I share some tips for doing usability testing with almost no budget, no special equipment, no special training, and no special labs.
Transcript:
I’m convinced that usability testing will turn a good product into a great product.
Usability testing doesn’t have to be expensive, it doesn’t have to be time consuming, and it doesn’t have to be complicated.
We did some formal usability testing in the early days of Feature Upvote, and in my opinion, this turned out to be one of the most valuable things we did in our first six months of operation.
In this video, I’m not going to tell you what usability testing is or how to do it. There are plenty of excellent guides already on the web. Instead, I’m going to tell you how we did it with almost no budget with no special equipment, with no special training, and no special labs.
First, we did our usability testing in person. We invited real people to my home office. In my opinion, the “watching in person” experience simply superior to trying to do it over the internet, and it’s way, way superior to paying somebody else to do the usability testing for you.
Second, we recruited people who don’t work professionally in making software. I think this is actually critical. Of course, it depends on what your software is and who it’s for. In our case, we decided we didn’t want coders and we didn’t want software designers and UX people because they get caught up in irrelevant details.
The coder might debate whether a link should open in the same tab or a new tab, or whether you should use placeholder text or not. A designer might start complaining about the typography or use of white space and other layout issues. What we wanted is people for whom software is a black box, kind of mysterious, but still a normal part of their work life. You see, we weren’t there to test the fine details. We were there to test the usability.
Third, we repeatedly told the user participants “we are testing the software, not you”. If there’s something confusing, if there’s an error, that’s our fault, not your fault.
People get really nervous when you watch them do stuff when they feel like they’re getting tested. So we really needed to deal with that in advance and to put them at ease and make them realize that they couldn’t do anything wrong.
Also, I emphasized that we were working on a test system, and that if they deleted anything or made a mistake, it didn’t matter because we were just going to wipe everything when they were done anyway.
Fourth, we got our whole team of 3 people at the time to watch the testing. We were having those kinds of debates you probably have in your own product team where one person says, “Well, I think users do things this way”, and another person says, “No, no, no, I know that users do things that way.”
There’s nothing like your team actually seeing what users do to discover that they don’t do it this way, they don’t do it that way. They do it the way they are going to do it. Solved a lot of debates!
Fifth, we encouraged the test participants to think aloud while they did the testing.
We wanted them to vocalize all the time, so we could learn about the thinking process they went through. We wanted to find out not just that they were having problems achieving the task, but why they were having problems, why they couldn’t find what they were looking for.
Now this required us to keep our own mouths shut no matter how much we wanted to help them. Very, very, difficult thing to do when you just want to tell people “click over there and you’ll see the thing you’re looking for”. In Usability testing -we had to keep our mouths shut.
Sixth, we tested with just four people, one at a time, so each session was conducted with one person.
Jakob Nielsen long ago demonstrated that you’ll find most of your product’s usability problems with just a few people. After that, the returns diminish rapidly.
Do the same round of usability testing with more than a few people, and you actually start wasting your money and your time.
Seventh, we tested against just a couple of tasks that we thought were really basic.
We learned quickly that what we thought as basic actually wasn’t basic at all, and we needed to really rethink how some of these tasks were completed.
Eight, after each session of one person, we adjusted Feature Upvote with what we learned.
The idea being that we would, tweak things a little before conducting the next session. It was a good way to make sure we were heading in the right direction with our changes.
Ninth – and finally – to get people to participate, we offered them a small amount of cash and a home-cooked Italian lunch afterwards. Now this is the advantage I have with an Italian partner!
Word got around, and people actually started asking if they could take part, if they could be participants in our testing, and believe it or not, we actually had to start saying no because we felt we had completed the testing.
Now, what type of changes did we make as a result of usability testing?
Almost every change was a simplification.
We removed things.
We removed options.
We made the language clearer.
We used more text and less icons or we added text to icons.
And the outcome?
Well, let me put it this way. Today, when we do customer interviews, we are told over and over how simple Feature Upvote is to use. I believe this is a direct result of the usability testing we did in the early days of our product.