Usability by Inspection

Doing code reviews? That's good! Code reviews are a big help. They ensure uniformity of code, teach people new design patterns, and often even help to avoid bugs.

Doing usability reviews?

Me either. But if you've got a product that has a UI, an easy thing to do to improve the product is to just sit down with a few people, maybe some that will actually use the product, maybe some managers, or maybe just some people that you can pull in to see what they think. That's more or less the gist of what I got from Larry Constantine's session on Usability Reviews.


Now, the first thing to realize is that a "usability review" is different than a "grouse session". I was once doing a demo for an internal tool my team was working on, and after I'd showed how the tool worked, during the Q&A period one guy spoke up to say, "Boy, does that interface ever look like it was designed by a programmer."

"Interesting," I said. "How would you improve it?"

"Oh, you know. It just doesn't look as sharp as it could."

Well, yes. Nothing ever does; but it wasn't too helpful to tell me that. So, when you do a review, you have to be specific.

But how can you be specific about a UI? A UI is just a UI, right? It either looks good or it doesn't.

Not at all! There are lots of basic principles of design that the people who make web sites for a living know about. Even if your organization really is full of web pages designed by programmers, there's no harm in teaching the programmers some basic principles of design. I have a couple of books on that subject, one by Mr. Constantine himself, which I didn't even realize until I'd gone in to the session. But the organization or team should probably lay down the fundamental precepts of design that they want to follow. The usability defects will be easier to objectively identify with that list in mind. Some examples of good design principles are: Availability, Feedback, Structure, Reuse, Tolerance, Simplicity. Check one of the books for some guides as to the specifics, but a usability defect violates one of these principles, or you could also say it is a probable cause of user delay and confusion. But it's not a usability defect if you just don't think it looks good!

So here's how you prepare for a usability review: First, organize a few use cases. You may already have them as part of your project, or you may just have to make some up. What you'll be doing is telling the users what they're trying to accomplish.

Then, get the folks together. At a minimum, you should probably have:

• A leader, to make sure everything moves along smoothly;
• A notetaker;
• A Continuity Reviewer. This is someone who is reviewing the UI specifically to make sure it is consistent with overall project guidelines, and with the other pages in the project.
• Users - people who will attempt to use the page. They can be actual customers; agile-style customers; or just people who were walking down the hall at the wrong time.
• A Designated Driver. This is someone who will perform actual mouse clicks or typing at the request of the users. This will depend on the exact situation - do you have a real application, or just some mockups? Do you have a big meeting room and a lot of users, or not? If not, the Designated Driver might as well just be the user.
• Developers/Designers. Developers and designers who worked on the page must never explain or defend design, argue with users, or promise anything. They may only find problems. Users do not count as problems.

It's an important point for reviewing anything that if a reviewer doesn't find problems, he's not doing his job. I always have to remind myself of that. But the people who worked on the application; the programmers, the designers, the developers; they will always be able to give a reason for why it works the way it does. Don't listen! Mr. Constantine suggested a "virtual air horn" - you get to pretend to be a big truck and blow the horn to get people out of the way. You must blow the virtual air horn whenever excuses, explanations, or rationalizations are made.
Next, have the users go through the use case or scenario you've designed. Introduce the scenario with an overview of context and user motivation. Read one step of the scenario at a time, and ask the users what they would do next. Users take lead in proposing actions. Never guide or prompt users! Help is limited to simple description or clarification. If the user has to ask for help, you've automatically got a usability defect.
For each defect that you find, the notetaker should note:

1. The feature or function that the defect is in;
2. The location; which web page it is or a screenshot of the GUI
3. Which design principle is being violated
4. A short description of the problem
5. The estimated severity of the problem. (nominal, minor, major, critical )

Ideally, these would be on a form the notetaker would be able to fill out.
You should probably allow one to three hours for the review. So that's it! Get out there and say goodbye to applications that look like they were designed by programmers!