Usability Testing Primer: What it is and Why We Need It

Not only do mHealth resources need to be engaging, factually accurate, and useful, they need to be usable. What is the difference between useful and usable you ask? Please allow me to step onto my soapbox.

A product is usable if an individual can achieve his or her goal with a minimum of effort. For example, let’s consider the microwave in your workplace. If a new employee can walk up to that microwave and immediately figure out how to make popcorn without needing to push extra buttons, it’s usable. If the employee needs to try a few different things, presses “cancel” and then starts again, it’s not so usable. If the employee sets off the fire alarm by burning the popcorn, then you work with me and I’m very sorry for the inconvenience.

When we design mobile apps, websites, and other mHealth tools, it can be easy to get stuck in the mentality of “this is how the user will engage with the application.” Although we hope users will know exactly where to click, it’s not always the case. If the application doesn’t solve user needs quickly, they won’t keep trying. Back to my microwave example, I’m more likely to use a very simple one if I can quickly figure it out (especially given my popcorn history). Similarly, users may give your website between 10 and 30 seconds to prove its value. If users can’t find what they need, what’s to stop them from leaving? This is especially true for our patients – if individuals are distressed or in pain, they’re less likely to be tolerant with a confusing website.

At T2 we try to increase usability of our mHealth applications in several ways. First of all, when we are planning our new apps, we try to test out the flow of information on paper before any software development occurs. We start with simple flowcharts, and then literally draw out paper prototypes. Just the other day, a colleague put a paper prototype in front of me and asked, “What would you expect to happen if you clicked this button?” He listened to my responses and then drew up a few different versions. Consider how much more expensive this refinement would be if it occurred after product development was complete.

We repeat this process once we start development, and throughout the whole product lifecycle. Here at Joint Base Lewis-McChord, we’re fortunate to get many volunteers from the military community to test our products and help refine our applications. Click here to read more about our T2 Technology Enhancement Center and how to volunteer.

Julie T. Kinn, Ph.D. is a research psychologist at DHA Connected Health.

The views expressed are those of the author and do not reflect the official policy or position of the National Center for Telehealth & Technology, the Defense Centers of Excellence for Psychological Health & Traumatic Brain Injury, the Department of Defense, or the U.S. Government.


Read other posts by Dr. Julie Kinn