posted by Matt Ward on Jul 26, 2011.
Despite the visual and aural similarities between the words, ability and usability are not the same thing. In this post, we will examine the difference and consider why simply being able to do something in a website or application does not automatically result in a usable product or interface.
As designers and developers working on either traditional websites, web apps or mobile apps, we can have a tendency to become too narrowly focused on features. We create lists of functionality (either on our own or together with our clients), and determine that our product needs to be able to do this thing or perform that action. As an example, over the course of the past few days, I’ve been neck deep in concepts of functionality, as I’ve been working on a number of flow charts that map out the proposed functionality for a new site that I am working on.
From such a perspective, it’s all too easy to set about implementing the listed functionality and, once it’s all in place, believing that we have created a feature-rich and usable product.
However, the presence of all the desired functionality doesn’t mean that the product is necessarily usable in and of itself. Being able to do something is not always synonymous with being able to do it easily. Often, the opposite is true. Key or advanced features can be buried so far down in a chain of menus and navigation, options and preferences, that it becomes all but impossible to perform a simple, desired action without the assistance of an instruction booklet or extensive road map.
To put it in simple, though somewhat mathematical terms: ability does not equal usability.
Can You Change the Ringtone?
As a perfect example of this issue, I recently had a conversation with a colleague that happened turn to the topic of mobile phones. With more than a hint of frustration in her voice, she told me about the difficulties she was having with her phone when it came to changing her ringtone.
Yes, the ringtone.
It may seem like a relatively mundane and commonplace sort of functionality, but my colleague had no end of difficulty in figuring out to make the change. I even grabbed her phone and worked on it for a few minutes myself and simply couldn’t any logical (or even illogical) way of performing the desired action.
With a bit more time and experimentation, we did, eventually, manage to figure it out. However, we had go through a number of different menus that involved the device’s somewhat obscure profiling system. To be honest, it would probably still take me at least another five minutes to figure it out if I had to do it again.
Fortunately for me, I use an smart phone which, when compared against my colleague’s phone, has a much higher level of usability. I can just open up my settings, chose sounds and then change my ringtone. It’s quick, easy and highly intuitive.
In both cases, the phone in question has the ability to change ringtones, but with my colleague’s phone the feature is all but unusable because it is so difficult to find.
Potential Keys to Usability
With this discrepancy between ability and usability, then, how do we take a product or interface from a state of merely being able to do something to the point where it can be done in a usable and intuitive way. Well, there are probably dozens (if not hundreds) of different things that we could talk about, but since our phone example was primarily a menu issue, here are just a few navigation-based ideas.
The biggest hurdle that both my colleague and I encountered in the mobile phone example was that we simply could not find our way down through the phone’s menu system to the required feature. We both tried all kinds of different paths. I know that I even tried the same ones several times.
Part of that repetition was clearly the result of thinking that I may have missed what I was looking for the first, second or even third time I looked. More than that, however, it was also bred from a natural human behaviour known as expectancy.
This wasn’t the first time that I’d changed (or, rather, tried to change) the ringtone on a mobile device. As such, I came to the task with a certain set of expectations as to how I would need to go about completing the task. Those expectations, however, were not only proven wrong, they were also frustrated by my inability to determine an alternate solution.
One common example that I like to use when talking about this kind of expectation (or, to put it another way, these kinds of design conventions) is the power button. Based on the near-universal symbol that has been adopted across a wide range of appliances and devices, I have developed an expectation through which the symbol should lead powering a device on or off. To a lesser, extent, I also expect that power buttons and/or switches would be marked with this symbol.
If either of these expectations were subverted in some way—perhaps by using a different symbol or using the symbol in another context—my expectations would be frustrated, and as a result I could be confused, irritated or even angered.
When designing a new system, always keep expectation in mind. If you’re at all familiar with your platform (web, mobile, desktop etc), you should have a basic set of expectations yourself, which can form the foundation. Beyond that, though, do your research. Examine how others have solved a given problem and take note of trends and patterns that you see.
It’s not about stealing or ripping off, though. The chances are good that these patterns have either emerged in direct response to existing sets of expectations, or that their frequent repetition is ultimately setting the groundwork for a new set of expectations.
There’s nothing wrong with a little bit of innovation in terms of functionality and navigation, but there does come a certain point when a user will want to rely on their own experience and expectations to guide them.
Traditional menu architecture tends to be very singular and hierarchical. Just think about a common drop down menu, either in a website or an application. Generally speaking, you will have your main menu items, beneath which there will be a number of sub menu items, many of which will trigger different actions or options. Some of these items may even have sub menus of their own, allowing for extensive multi-dimensional navigations.
This works well (up to a point—dozens of nested sub menus can become burdensome), but there is really nothing out there to state that the hierarchical pattern is the alpha and omega of navigation. This is especially true on the web. Based on the very nature of the hypertext, internal links provide users with the ability to move from one page to another, based on how they are responding to content, rather than how that content is arranged.
Remember, that they key to any information-based site (or application) is to get users to what they are looking for as quickly and painlessly as possible. From a usability standpoint, multiple, well-considered and well-managed access paths provide users with a variety of different ways to arrive at the same point, thereby increasing the probability that they will, in fact, get there. Wikipedia (and other wikis) are a great example of this. In fact, with the possible exception of search, the interlinking of articles is likely the most important form of navigation on their site.
Of course, as with nearly anything, we still need to work within reason. Having too many paths can be paralyzing, confusing or dizzying—possibly even all of the above—and lead users along a continuous cycle of link-clicking. Focus on logical navigation paths that will make sense to different types of users, not just on creating as many different paths as possible.
After all, it’s called the web, not the maze.
Another technique that can be very helpful, especially in large and more complex sites or applications, is the use of contextual help—that is to say helpful cues, hints or suggestions that are actually provided based on a user’s actions or their current context.
For instance, when I was developing Survd, I knew that there would be some elements of the interface that new users might not grasp immediately. With this mind, I elected to add simple, contextual help icons (rendered as a familiar question mark) beside some of these items. When the user hovers over these icons, a simple tooltip appears explaining what the interface item is and why it’s important.
I’ve found that it’s a simple, noninvasive way to increase overall usability (I’ve even released a super simple little jQuery script that can allow you to do the same thing in your site or web app). Plus, for more advanced users, I also added in an option to turn the contextual help off. This way, users who are more familiar with the interface and don’t need the help can actually remove the icons entirely.
Another form of contextual help might involve tracking the user’s behaviours, either within a single session or across multiple sessions. Then, based on those behaviours, you can provide additional cues or shortcuts that will allow them to accomplish what they’re trying to do more quickly and efficiently.
Google’s Chrome browser does this really nicely by providing a default homepage that lists the eight sites that you have visited the most recently. It’s a nifty little feature that actually adapts to your browsing habits, and which could be migrated to a number of different types of applications.
There are, of course, many other things that we could talk about when it comes to how to improve usability. To come back to the point at hand, however, the important thing to remember is that just because you can do something doesn’t mean that a product has good usability. Instead, usability is measured (at least from my perspective) by the relative ease with which the feature is accessed or the function is executed.
As designers, I believe that a key component of our job should be facilitate that ease as much as possible.Post A Comment
Also from Echo Enduring Media: