Lisa Jo Elliott, PhD, spoke at Code for KC’s Learn night on July 16, 2018. Lisa discussed usability testing and how to find where users lose their way in an application. 

Many of us already know the benefits of user testing. It can help us find issues early on in the process or after it’s live. Solving these issues usually leads to a better design. Learning to do user testing is not complex. Lisa Jo Elliotthas trained many user professionals. She talked about the basic procedure, the steps to take, tips and tricks from years of user testing, and how to interpret the results for the development team. This discussion gave attendees a better understanding of how to use the tests to their teams’ best advantage and how to do it on their own. 

Lisa started with Code for KC when she was a professor at Missouri Western, where she ran a very successful usability testing master’s program. She then moved to Penn State University to teach engineering students. 

Lisa explained that most people are aware that usability is important. This is because usability is crucial for an app’s success. Not only that, but apps can even be sued for a lack of usability. But this doesn’t mean a company needs a usability practitioner to test usability. Developers can do the work themselves by following guidelines. 

Usability has a beginning, middle, and end, just like many processes. Before testing begins, you must have a mockup of your app. This can be a live site or one that’s very similar to what yours will be. The mockup can be on paper or in powerpoint form, as well.  

Once your mockup is complete, you need at least one question before testing starts. Then you need tasks that you want users to be able to do with your site. The last thing you need during this preparation phase is a red route. A red route is a route you want people to follow in order to do whatever task it is that you want users to be able to do with your site. 

All this preparation ideally happens quickly. Because so many apps are so similar, you have to get yours tested and on the market before others with the same idea finish theirs. This means it is best to go right to mockups and testing. 

After all the preparation work is done, you need some simple things. These are a location to carry out the testing and users. The ideal location is anywhere you’ll be allowed to do the testing where you’ll find people who would actually want to use your app. It’s important to compensate testers for their time, so be prepared to buy them snacks, coffee, or whatever is appropriate in your chosen location. 

You’ll need to bring some basic things to your testing. These are a large amount of paper, pens and pencils, two of whatever device you plan to have people use, two sets of batteries or chargers, and two people to run the testing. One of these people will be observing and documenting. Lisa does not recommend recording the testing unless your team requires it. 

It’s a good rule to start with five test users, or to go until you start to see the same major problem more than once. This is rapid, low-stakes testing because you can go back and fix the problem and then proceed with another round of testing with little inconvenience.

Testers won’t want to tell you about problems they have with your app, so make sure to encourage their honesty and follow up with something to make them feel better about “messing up.” 

Lisa shared that the first time testing will likely be difficult, but the process gets easier the more times you go through it. It’s good practice to do a pilot study to work out any unexpected issues that may arise. When you have your list of problems from your testers, it’s best to put them in order of priority, and this process may cause some tension within the development team. 

Finally, stop testing when your question is answered and the major problems on your red route are fixed. No app will ever be perfect, and you’d spend months and months testing if you try to fix every little problem you find. 

Code for KC hosts Learn Nights every third Monday of the month from 6-8 pm.

Further Reading