The single evaluator will miss most of the usability problems in an interface. Averaged over six projects, single evaluator found only 35% of the usability problems in the interface. It is recommended to use about five evaluators, and certainly at least three.

The differences between heuristic evaluation sessions and traditional user testing are that observer answers questions from the evaluators during the session. For traditional user testing, one wants to discover the mistakes users make when using the interface. For heuristic evaluation it would be unreasonable to refuse to answer the evaluators’ questions.

You meet members of your team to choose the type of user who represents audience for the interface. You also determine tasks you expect this user to do. Then you sketch on the paper all the windows, menus, boxes pop-up messages which are needed to perform those tasks. The most important thing is, you don’t have to have a working version of the interface. You use whiteboard or make a paper prototype.

After you have a prototype, it is a time to conduct a usability test. You bring in a person who is representative of the audience. This user will attempt the tasks by interacting directly with the prototype – click by touching buttons etc. One person from the team is playing the role of “Computer,” manipulating the pieces of paper to simulate a computer. Another person is facilitator who conducts the session.

One of the graph from the book shows survey from 2002 among usability professionals. “What is the importance of paper prototyping to your work?” Answer: 15% told it is marginal, 56% useful, 30% essential and 0% useless.

The team has to analyze the problems and decide how to fix them. The biggest question in this point is – should the team work on changes or absolutely redesign the whole system? Before I make any drastic decision, it is a good idea to implement as quickly as possible the least changes which could fix the problem, then test the project again. To do so, my team has to focus on precise points. The comment “The colors of navigation are not matching with rest of the page” is much more useful than simple observation “Navigation sucks.” No general complains are excepted! A precise explanation of problems and valuable suggestions allow me make quick and accurate changes to the project, so I can very fast see if we are on the right track with a current design. However, in most cases any “not bad” design can be fixed, and it takes less time than a complete redesign. Typical problems are: wrong arrangement of elements on the page, not correct names chosen to describe categories in a navigation, some elements on the page are too much or not enough visible, a wrong color palette.

…such as:

• user’s work experience (kind of job, years of experience etc.)
• general computer experience (types of applications used etc.)
• specific computer experience (experience with hardware and specific operating system)
• experience with a kind of product we design
• experience with a similar products to this we design

Designers have to think “broadly” about users:

• don’t just consider people who are experts
• don’t limit yourself to the current or local market
• think about expansion, don’t limit too much a group of people who you develop a product for
• make your product easy to use for novices and experts

How many people should we include in a test? It was found that:

• about half of all major usability problems are detected with 3 participants
• 80% of usability problems are detected with between 4 and 5 participants
• 90% is detected with 10 participants

A typical usability test now includes 6 to 12 participants, which are divided into 2 or 3 subgroups.

It is like writing a script for a movie and it is fun. During a process of creating such a character we have to decide about all details, such as: name, sex, age, occupation, marital status, temper etc. All facts matter! The next step is to put our hero into some difficult but real situation in which the person has to use our interface. By imaging how the character will act in such a circumstances and what kind of difficulties he/she can meet, designers learn how to design more user friendly interface for a particular project.

An example: we create a website, an eCommerce site to sell eyeglasses. Our character is an older, rich person with a vision problem, siting in his fancy apartment in Manhattan. Right away a good designers can assume: “hmm… big font is needed. However, since he doesn’t care about the price, a font size of this element can be nough small to don’t let him see it clearly ;). The client of ours sells preatty expensive eyeglasses.”

The paper prototyping was already used in early 1990s by companies such as IBM and Microsoft. According to a survey of usability practitioners from July 2002, answers for a question of ‘usefulness of paper prototyping’ are as follow: 15% of responses claim that the usefulness of paper prototyping is marginal, 30% that it is essential, 56% that it is useful.

What we have to point out, nobody said that a paper prototyping is useless. Some of the benefits of this technique are: it provides important user feedback early before the development process and implementation. It also allows rapid experimenting with many ideas.

An example of paper prototype could be a process of user interface designing. You hand-sketch versions of all the windows, menus, pages, pop-up messages etc. You can then ask somebody to interact with your prototype. When user ‘click’ on the elements of your sketch you can show him other pages with screens which will appear after the particular interaction with your interface. By doing this, you can quickly discover which part of the interface doesn’t work well. Because you work with a paper, you can easily modify it right away.