10 (OK, 12) Usability Principles to Consider

First of all, there are no users - Nobody considers themselves a user, so we shouldn't design for users. We all play multiple roles - I'm a researcher, consultant, author, traveler - and a customer - but not a user. Instead we recommend designing products for your customers, for travelers, for scientists. Not for "users."

Interaction transparency - In the same way, we don't want to "experience" our tools, we want to do work with them and see the work happen. If you're designing tools for complex interaction, or even a simple website, you want interaction transparency. Transparent user interfaces require evaluation that's sensitive to context, tasks, goals, and values.

Using the same usability test method for every stage of product development only ensures you will repeat your results. We exercise a repertoire of methods, and work with you to select the best approach for the testing purpose. Interested in understanding potential response to a concept? Looking for validation of the final user interface before piloting? Use the right method for the best answers.

Testing can be expensive, and you only have an hour with each participant. What do you need to know about most? Standard usability testing covers the waterfront, but can be shallow and miss big areas of opportunity. We seek to understand the most important areas of the product, and evaluate those areas in context.

Context is critical when understanding how users approach complex task with your software. Usability is not making software “easy,” its about understanding how to best fit the interface to task needs. Usability lab and similar artificial environments have been found to induce user “demand” artifacts, where their expectations are set by the test environment. Also, users offer better ideas when they can relate it to their work, so we use field tests whenever possible.

You’re really looking to improve usability by making appropriate revisions to a user interface. Completely “neutral” evaluators often miss the point by staying removed from the purpose of the design, or they don’t have design background. Therefore, their “design recommendations” will fail to consider the complexity and dependencies of the multiple requirements of the user interface. Designers that test offer useful insight into your problem, whereas “testers that design” can result in less effective interfaces.

Measures are expensive – the more you gather, the m ore they must be analyzed to make sense of the data. Attending to multiple measures distracts evaluators from seeing important emerging interactions - a significant hidden value. Multiple measures can also interfere with each other – so only gather metrics that address the business decision and user need.

Some of us have been evaluating software products before anyone ever heard of  Redmond (1983). We’ve built several usability labs, and found their limitations. We’ve done every kind of usability test in the books, and know what to use and when. We look to give you results and save time and money resources.

The user’s needs don’t define the entire product. We understand the trade-offs between a business vision and user acceptance. The necessary business processes underlying the product must be carefully represented. Skill in designing appropriate test approaches gains access to both the business and user’s needs.

We believe the user should be an active participant in design improvement, not just a human test instrument. Your users have knowledge of their jobs, and know what they prefer. We tap into this source of informal design guidance during the test.

With a design problem, you’re making a business decision, not assessing the deadly consequences of reactions to a new drug in a clinical trial. You don’t need statistical significance – only a robust data set. Sometimes you’ll get robust data with 6 users – sometimes you need 24. But no one approach fits all tests.

Giving you a test log, a videotape, a test report, and verbatim comments is probably more than is necessary. From running hundreds of tests, we’ve observed that usually the right design changes are often obvious within the context of the test. We typically offer a readable, supportable test report and  videotape the appropriate interaction necessary for analysis and decision making. Micro-level techniques are overkill - for example, instrumentation of the user’s keystrokes offers no contextual information useful in design decisions. And who are you paying to analyze extensive test logs? Ask about our documentation.