- Interviews/Observations: One-on-one sessions with users.
- Focus Groups: Often used in marketing well before there is any kind of prototype or product to test, a facilitated meeting with multiple attendees from the target user group.
- Group Review or Walk-Through: A facilitator presents planned workflow to multiple attendees, who present comments on it.
- Heuristic Review: Using a predefined set of standards, a professional usability expert reviews someone else's product or product design and presents a marked checklist back to the designer.
- Walk-Around Review: Copies of the design/prototype/wireframe are tacked to the walls, and colleagues are invited to comment.
- Do-it-Yourself Walk-Through: Make mock-ups of artifacts, but make the scenarios realistic. Walk through the work yourself.
- Paper Prototype Test: Use realistic scenarios but a fake product.
- Prototype Test: A step up from a paper prototype, using some type of animated prototype with realistic scenarios.
- Formal Usability Test: Using a stable product, an animated prototype, or even a paper prototype, test a reasonably large number of subjects against a controlled variety of scenarios.
- Controlled Experiment: A comparison of two products, with careful statistical balancing, etc
- Questionnaires: Ask testers to complete a formal questionnaire, or matching questionnaire.
- Heuristic Review
- Prototype Test
- Formal Usability Test
However, the heuristic review relies on trust between the reviewer and the program maintainer. If that trust is lacking, or if the maintainer doesn't "buy into" the usability review, the maintainer will likely dismiss the heuristic review. This is one reason why many open source software programs lack good usability. From a previous conversation with Eric Raymond, Raymond commented that most programmers view "Menus and icons are like the frosting on the cake after you've baked it" and that any results that try to provide correction to usability is "swimming against a strong cultural headwind." While a mixed metaphor (intentional) it's very descriptive of the problem.
A more compelling way to achieve usability "buy in" with developers is to perform a usability test. There's nothing quite like seeing a user experience problems with your program.
In my next post, I'll share some notes on how to do a usability test, and planning for your usability test audience.