USER INTERFACE DESIGN AUDIT

Often, the best place to start is with a product you already have. An outside perspective like mine helps you to see the strengths of your existing product—as well as its shortfalls—and possibilities for the next version.

Sometimes interface problems are found by development team members themselves; an established product will have reports from users that reveal problems. There may even be results from usability test. No doubt there is also a wish list of new features. How do you know how to balance and synthesize these wishes, problem reports, and the needs of possibly untapped markets?

The hard part is suggesting solutions. When users, or even development team members, make suggestions for improvements, it's usually best to take these suggestions as very specific descriptions of the problem instead of as solutions that are ready to implement. Confused users don't have the perspective to solve difficult design solutions, even though it's tempting to obey them since they are your customers. Executives involved in products are often sources of many suggestions themselves, and they are even harder to ignore than customers, but again, you often need to work backward from their solutions to discover the problems that prompted them.

My experience can save you expensive and time-consuming cycles of user testing and revision. A design audit works like this:

• I spend time working with the product, with only the information that would be available to a typical user. Ideally, I will not even have received a demo; just the product and the manuals. Of course, some products require knowledge of a problem domain.
• I take detailed notes on problem areas while I'm using the product.
• I watch your customers using the product in the real world. I'd like to do this first, but it would bias my own first impressions.
• I review logs, like web logs, or documents created by your customers that show how the product is used, and also any feedback you have to share.
• I think for a while.
• I create a detailed report of changes to make to the existing product, or a mock-up or prototype of its replacement, depending on what you request.

This usually takes a couple of weeks for a moderately complex desktop application. One assignment resulted in over 100 change requests. Some of these were as simple as changing the name of a menu item, and others were more fundamental. I'm pretty good at finding bugs that are not strictly user interface issues, and I pass those along, too!

Home  About  Services  Philosophy  Contact  Site Map
Last updated by Brian Krause, brk@adducive.com, August 19, 2002
Adducive   Redwood City, CA   650-274-2415