Usability testing is a great idea for anyone developing apps. There are few experiences for a developer more eye-opening than watching a user interact in unexpected ways with his creation. I learned about traditional usability testing from Don Levan of Vanguard Custom Software. Under this scenario, a user with no prior experience with an app is asked to attempt a simple task within the confines of the software interface while speaking aloud about her experience. The observer records the user’s actions and voice, and takes notes. This information is then analyzed to improve the user experience.
For years before learning of this traditional approach, I was already doing ad-hoc usability testing. It happens naturally as part of training new users on your FileMaker creation. The best (and sometimes most maddening) users to study are the ones who leap ahead of your explanation and make “inappropriate” clicks or keystrokes based on experience with other apps, OS-level conventions (double-click anyone?), or just plain curiosity. One learns to expect the unexpected under this scenario, and this is valuable feedback.
Wait – there’s more.
What has been truly revealing to me is watching users after they have become experienced with the app. Somewhere around the three-to-six month mark, it all starts to click. Suddenly your tentative, confused user is zooming around in your creation faster than you ever could, and this is gratifying; but more often than not, I sit in horror watching as she works around some anomaly in the system that I was not aware of. Maybe it’s a small idiosyncrasy of the business process that I was never made aware of. Perhaps it’s an extra bit of data that was not accounted for, so it’s going into a notes field where it can do little good. It might even be a bug that never got reported, either because it was not recognized as such, or was not deemed important; but the worst thing for me is when I realize I could have done just a little bit more work on the interface and removed a major speed bump in the user experience. It never ceases to amaze me what people will put up with.
None of this could have been apparent in that earlier stage of usability testing, when the user’s familiarity is low, speed is slow, and anxiety is at an all-time high. Think of test driving a high-performance sports car in rush hour traffic – there’s no point. The important nuances of that machine will only be revealed at higher speeds on an open road.
In fact, I would place equal or even greater importance on testing for usability at this later stage. I often find myself taking feedback in the early stages with a grain of salt. There are lots of problems that can be solved with quality training. Who hasn’t dealt with anxious supervisors who have encountered the “type over data in browse mode while mistaking it for find mode” error? I always advise my clients to wait a while before attempting to address such problems with programmed bumper guards, and it almost never comes up again. Here’s the point: in the grand scheme of things, your users spend one- to five-percent of the app’s lifespan learning how to use it, and the other 95-99% as more or less experts. It makes sense to design for the latter.
I have now begun to formalize expert level usability testing into my standard business process. It’s not really very different from what I described at the beginning of this article: give the user a task, at which he is now an expert, and ask him to talk you through it. Then try to keep up, because this time it might be you saying things like, “wait, go back – I didn’t see what you just did there.”
Ultimately, this is yet another opportunity to deliver additonal value to your clients, and improve the overall quality of your products over the long term.
Want more? This and related ?topics will be covered in more detail in my session at this year’s FileMaker DevCon: “Long Live Your App!”
