More Questions from Usability 2.0

by May 20, 2007

In Usability 2.0 Questions, I wrote up my responses from last month's Silicon Valley Web Guild event with Sean Kane (Netflix) and Jon Wiley (Google). As a follow on to that article, here are a few more questions with my responses. To get a perspective from the entire panel, check out the session video.

Q: With the rich interactivity of a Ajax-powered Web applications, clearly the user is getting more but what challenges do these technologies create from a usability perspective?

Ajax, Flash, and other rich Internet application technologies enable element-level (micro-level, if you will) interactions and adaptations. What that means in practice is that certain interactions (most notably page reloads) are no longer necessary. We can update just a portion of a page with relevant or personalized data or actions and not the whole page. We can also include rich interactions within our Web applications that enable the type of direct manipulation people experience with their desktop applications.

Rich, element-level interactions allow us to enable lightweight interactions like voting on digg or rating a movie on Netflix. But because there is no page reload, feedback becomes a key usability consideration. People no longer have a page refresh that tells them their action is in progress or complete. So we need to explicitly let people know the result of their actions. That includes a number of states: in progress, successful, and unsuccessful for starters. Each of these states needs to be tracked and communicated.

We also need to communicate what actions are possible so people have a sense of what they can accomplish. Unexpected actions like drag and drop, in particular, require affordances that provide clues about their use.

I also find that some Web application designs have a tendency to overuse in-page micro interactions. When each element has multiple states or all the actions and content on a page update in-line, people may become disorientated. In some of these cases, a full-page reload might actually work better. Just because we can design all our actions to happen in-line doesn’t mean we should.

Q: Some companies seem to value form as well as function whereas others appear to value function only. Does form not provide as much value for usability?

I guess it depends on how you understand form. Many companies still think of visual design as “making things pretty” due to its traditional role as stylist. But visual design is the voice of the interaction design and information architecture most because people are only able to interact with a Web application through its presentation layer. So form is actually responsible for communicating function.

Q: What are some of your: best practices for usability testing, biggest bangs for your usability dollar, or usability sins?

For any type of usability testing, I’d say a crucial best practice is objectivity. Being able to observe what you are seeing people do without a subjective viewpoint is one of the traits I’ve come to admire most in usability professionals. Part of that is being open to new insights. If you have a predetermined point of view, you’re likely to mostly see what you assume you will beforehand.

I’ve always been a fan of RITE (rapid iterative testing) and triangulation (or perhaps a better term is cross-fertilization) of multiple data sources. RITE testing gives you the ability to quickly adapt to issues and opportunities being seen as testing goes on. Data cross-fertilization gives you both qualitative and quantitative information, which paints a fuller picture of what’s working. For example, live site testing may tell you what people are doing on your site but it won’t tell you why. Lab testing, on the other hand may tell you why people may do things but it may not be an accurate predictor of large-scale behavior. When combined, however, these and other techniques can paint a fuller picture.

As far as usability sins, there are a couple scenarios that come up frequently in testing: discoverability and complete cognition. I bring up discoverability because usability testing is often used to evaluate the effectives of specific Web application features and a common finding is that the feature being tested is not discoverable. Most times, I believe that is to be expected. People do not experience features in isolation, they experience them in the context of tasks and goals. As such testing the discoverability of a feature for feature’s sake may lead to make decisions that don’t take the full context of product experience into account.

Complete cognition on the other hand, is the expectation that people need to understand exactly how they accomplished a task. A more relevant measure is how they did or did not accomplish the task they set out to do. Often, it’s unreasonable to assume people will completely understand how and why something works. So considering that a failing of the design doesn’t help address actual usability (usage) issues.

Q: Most products and services directly affect the bottom line. Yet it is difficult to quantify the ROI (return on investment) for usability. Why is that?

For starters, there are a lot of examples where bad usability practices can lead to increased revenue. Confusing navigation systems may increase page views as people stumble around. Lack of visual design can reduce the difference between ads and content leading to higher click-through rates.

In the long term, of course, these aren’t sustainable models as people will gravitate toward better experiences. But before viable alternatives emerge, people will put up with a lot to get utility they can’t find elsewhere. Joshua Porter and I recently had a conversation about this lifecycle of design and where we ended up was that there are phases in the life of a product or a technology where usability becomes increasingly important. Depending on where your product is in that cycle the ROI of usability may change. I don’t think most attempts to quantify the impact of usability on the bottom line take this context into account.