Since starting at the iSchool, the term “usability” has become one I hear, think, and talk about most days of the week. This semester, in fact, I’m in two usability-related courses: a workshop on usability testing, and a human-centred design course. In another class, I’m working on a project on the usability of online privacy policies (spoiler alert: they’re not very usable).
We talk a lot about usability – but we talk a lot less about usefulness, as one of my professors pointed out in lecture this week. This has been on my mind a lot lately.
At one of my former jobs, we had to use a project management system that was, frankly, quite clunky. It was difficult to learn, finicky, and frustrating. At the same time, it was really useful to have one place where you could see everyone’s progress on a given project. So despite the fact that the system was frustrating, we used it. It was not an uncommon sight to see someone yelling at their computer over it, but it was rare that anyone neglected it.
Undoubtedly, that system had major usability problems, and resolving those issues would likely foster a happier workplace. But despite the headache, once you figured out its idiosyncrasies over time, you could work around its problems fairly effectively and get a lot of benefit from the system. In other words, since the system was useful, we figured out how to use it; and in that interaction, it became usable.
In my classes, we’ve been engaging in different methods of usability testing to build our UX toolkits. Recently, I worked with a team on a heuristic evaluation of the Scotiabank Toronto Waterfront Marathon site. (You can view our report here.) While there are several usability problems with the site, what struck me most was the depth of information on the site. Before it needed a usability intervention and the aid of developers, what it really needed was an editor to ask what information is actually useful to the site’s key user groups.
As my professor pointed out in my usability workshop, there’s really no such thing as a “user-friendly” product; usability is the outcome of an interaction between a given user and a given interface (or otherwise), and what works for one person may very well not work for someone else categorized in the same user group.
We can certainly improve products by testing for and striving for usability – but the first question we need to ask, no matter what our role is in the development process, is what problem we are actually trying to solve. Before we can make it usable, we have to make it useful. Usability, both through testing and evaluation and through users’ will and ability to adopt useful products, will follow.
Image by Ragesoss via Wikimedia Commons.
