How do you go about prioritizing user experience issues?

Crossposted from the new Voices of Experience forum at Improving Customer Experience :

At work we’ve recently begun some serious (read: crash program-style fast and furious) work on an embedded software interface for a small handheld device. It isn’t a sexy device, few consumers will see or want it, but I suspect some of the lessons there map to web pages, packaged software, etc. (I’m omitting customer service stuff on purpose and focusing only on user interface concerns here.)

Some of the most important issues are low-hanging fruit, and some are real sticky problems involving a confluence of labeling, workflow, IA, and tricksy device limitations. They are important because they represent difficulties testers and/or users had with the top use cases.

It seems like I’m begging the question, but I’m not. A top use case, for us, is one that is crucial to a person’s adoption of the device, day-to-day use of the device, or is bound up with a safety or security concern. There could be many of these, but likely there are even more use cases that are not “top” in this way.

Adoption: concerned with the out-of-box experience. How easy is it to get started, enter initial settings, etc. The use cases in these areas are primarily “for the business,” but without smooth function in key adoption use cases, the user will abandon, make a return, incur additional support costs, be forced to turn to the manual, become frustrated, etc. Successful design of the components of these use cases will result in initial user feelings of ease and quality. In a typical eCommerce environment (boutique sites with not much repeat business) these might be related to browsing and finding products, adding them to a cart, checking out for the first time. These are often “gating” use cases, where failure would prevent further progress.

Day-to-day use: concerned with the most frequent and/or useful repeated operations that a user is likely to encounter. The use cases in this segment are definitely “for the user” and affect the user’s overall feelings of ease and sure-footedness using the device. In a heavy-duty eCommerce environment such as Amazon this might include things like reviews and ratings (reading), wishlists, serendipity links, saved shopping cart contents, payment management, order history, etc.

Safety/security: if a feature or operation is critical to the safety of the person using the device or the security of the data contained within, then it behooves us to make that function as well as we possibly can. eCommerce: account management, login, etc.

With an existing product or launched site or service you can learn where the problems are from a variety of sources: support calls, returns, education and training (trainers will talk your ear off about what parts of the thing are tricky to explain or require extra handholding), the sales staff (who may hear complaints in the field). This introduces office politics and costs at various functional areas into the mix. There may be a revenue, support, or rework cost that is so high, once it is trapped, that it would be folly not to handle it. Without cost information, silencing the most frequent complains is often a good place to start.

For a new product, ideally you have a solid sense of what the top use cases should be, if the product is at all well-defined. This is where user testing comes in. You’d be surprised how many top use cases are either A) more badly broken that we imagined, or B) seem potentially broken but actually present no problem to the user. You can only identify how well and truly broken (or OK) a use case is by testing the darn thing with actual people, one on one. It doesn’t take many and doesn’t have to be expensive, and using user testing as a design input in this way can help immeasurably in the identification and dispatch of the real important problems.

You’ll notice that for both existing and new products, we can measure the effect of our work on the problems. Costs and incidence go down for existing products, and testers are more successful navigating the product’s top use cases in a newly-designed product. Either one can be measured numerically, which your boss will like.

Leave a comment