An example of an interface that can be learned quickly—so quickly that the learning period is often forgotten—is the multitouch gestures on the iPhone. It’s not natural to associate pinching your fingers together with zooming out. That’s not something that happens in our everyday lives. So why does this gesture seem to intuitive? Because Apple has spent millions of dollars on commercials and tradeshow demonstrations showing this gesture over and over again. Your friends show it to you when they’re trying to convince you to buy an iPhone. Steve Jobs shows you the pinching gesture when he’s introducing the iPhone. By the time you’ve bought an iPhone for yourself, you’re familiar with the simple gesture and it just seems intuitive.

During HCI 522: “Scientific Methods of Human–Computer Interaction”, we wrote a blog entry each week along with a class presentation. I’ve mirrored my blog entries here in the past.

Now we’ve collected our favorite blog entries from that class and compiled them into a book: Shiny Happy Users. We published the book through lulu.com. There’s a hardcover edition and a paperback edition. And if you’re not convinced to buy a copy of the book, you can even download the PDF for free.

In addition to the book, we’ve created a companion DVD that contains our video presentations and slides.

And if all this weren’t enough, the books and DVD are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike license. That means that you can give copies of our work to your friends and you can make derivatives of our work. Some examples of derivatives would be: translate it into a different language, rework the essays into lecture notes for a class, and transform the work into a different format (say, for e-book readers).

Visit the Shiny Happy Users website for more information and samples of the essays and presentations.

I did all the typesetting for the book, so I’m sure there are plenty of errors and typos. if you find any, please let me know!

My presentation this week is a short collection of pet peeves and tips for writing survey questions.

1. Make answers mutually exclusive.

   How many days per week do you wear socks?  0–1  1–2  2–3  3–4  4–5	How many days per week do you wear socks?  0–1  2–3  4–5  6–7
   BAD	GOOD

   If I wear socks three days a week, I don’t know which option I should select in the first example. In the second example, the choice is obvious.

2. Don’t make them reach for their calculators.

   How many hours a year do you use the Internet?	How many hours a day do you use the Internet? How many hours a week do you use the Internet?
   BAD	GOOD

   In the first example, I would have to estimate how many hours a day I spend on the Internet and then multiply that a few times to get the hours per year. That’s a lot of work! Instead, you should estimate what the proper time period should be when writing the question. If you anticipate that people use the Internet a few hours each day, then ask for the answer in hours per day. If you suspect that they only use the Internet a few minutes each day or a few hours each week, change the wording accordingly.

3. Provide a neutral option on the Likert scale.

   Cold pizza is good for breakfast.  Strongly disagree  Disagree  Agree  Strongly agree	Cold pizza is good for breakfast.  Strongly disagree  Disagree  Neither agree or disagree  Agree  Strongly agree
   BAD	GOOD

4. Make it clean when the respondent can provide multiple answers.

   Which flavor of ice cream do you like?  Vanilla  chocolate  Strawberry Which pizza toppings do you like?  Pepperoni  Cheese  Sausage  Anchovies	Which flavor of ice cream do you like? (Choose one.)  Vanilla  chocolate  Strawberry Which pizza toppings do you like? (Choose all that apply.)  Pepperoni  Cheese  Sausage  Anchovies
   BAD	GOOD

   It should be obvious to the respondent when they can select more than one answer. In the second example, I’ve added the notes “(Choose one.)” and “(Choose all that apply.)”. I’ve added another small visual clue by changing the selection circles to boxes to indicate that more than one choose is allowed.

5. Don’t provide so many options that it’s difficult to choose.

   What is your favorite color?
   Amaranth  Amber  Amethyst  Apricot  Aqua  Azure  Beige  Black	Blue  Brown  Cerulean  Cinnamon  Copper  Coral  Cream  Crimson	Cyan  Emerald  Eggplant  Forest green  Fuchsia  Gold  Goldenrod  Grey	Green  Indigo  Ivory  Jade  Lavender  Lemon  Lilac  Lime

   This one is pretty self-explanatory. If you overwhelm the respondent with choices they’ll likely give up and pick the first one that seems reasonable.

6. Don’t exclude possible responses.

   How many hours a week do you spend watching television?  1–5  6–10  11–15  16–20	How many hours a week do you spend watching television?  none  1–5  6–10  11–15  16–20  more than 20
   BAD	GOOD

   You should consider the edge cases. For instance, the respondent may never participate in an activity or perform some task. Also, you shouldn’t put an artificial upper limit on the responses.

7. Placing the demographic questions at the end of the survey may result in more complete responses since the respondent has already invested time in the survey.
8. Instead of asking “How old are you?”, ask “In what year were you born?“ You’ll often get more responses this way.
9. If you’re asking an open-ended question and provide lines on which to write the answer, double-space the lines so the respondent has plenty of room to write. (I hate it when I have to squeeze my handwriting into a 1/8-inch high space.)
10. Clearly indicate which questions are required and which are optional.
11. When requiring personal information, explain what you will use it for.

Do you have any pet peeves or tips regarding survey questions? If so, I’d love to hear them; leave a comment below!

References and Resources

• Kevin’s presentation slides (PDF)
• Kevin’s presentation video (Quicktime movie)

Donald Norman wrote an article suggesting that the “study first, design second” approach should be turned on its head—that you should design first, then study.

Here are some juicy quotes from the article:

All of us usability theorists have long argued for iterative design, trying to get rid of the lengthy, inflexible linear project schedules that stymie flexibility and change, that slows up projects. Instead, we have championed iterative design, with frequent, rapid prototyping and frequent, rapid test.

But wait a minute, our continual plea for up-front user studies, field observations, and the discovery of true user needs are a step backwards: they are a linear, inflexible process inserted prior to the design and coding stages. We are advocating a waterfall method for us, even as we deny it for others. Yes, folks. By saying we need time to do field studies, observations, rapid paper prototypes and the like, we are contradicting the very methods that we claim to be promoting.

I recommend reading the article in full. I would also love to see some discussion on the topic here. Why do you agree or disagree with Donald Norman?

References and Resources

• Kevin’s presentation slides (PDF)
• Kevin’s presentation video (Quicktime movie)
• “Why doing user observations first is wrong” by Donald Norman.

All projects should include research.

In an article I found recently by Dan Saffer, he provides a counterpoint to this widely held belief.

Saffer claims that there are only eight conditions that require user research. If you or your project doesn’t fall into one of these categories, you shouldn’t need user research and can rely solely on the designer’s experience.

1. You don’t know the subject area well.
2. The project is based in a culture different to your own.
You don’t know who the users are.
3. The product is one you’d never use yourself.
4. The product contains features and functionality that are for specific types of users, who are doing specific types of work, work you don’t necessarily do yourself.
5. You need inspiration.
6. You need empathy.
7. You don’t have much expertise.

Some questions that this raised for me are: Are there any projects that fail to fall into at least one of these conditions?

What do you think?

References and Resources

• Kevin’s presentation slides (PDF)
• Kevin’s presentation video (QuickTime) — seek to half way through video
• “Research Is a Method, Not a Methodology” at Adaptive Path by Dan Saffer.

In Carolyn Snyder’s book Paper Protyping: The fast and easy way to design and refine user interfaces, paper prototyping is defined as:

Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person “playing computer,” who doesn’t explain how the interface is intended to work.

Paper prototyping provides a fast and cheap way to test many user interactions. It is especially useful in conjunction with an iterative software design process. There are, however, some problems that paper prototyping won’t help you uncover: time delays, scrolling, colors, images, and fonts.

References and Resources

• Kevin’s presentation slides (PDF)
• Kevin’s presentation video (Quicktime movie)
• Paper Prototyping companion site by Carolyn Snyder
• “Paper Prototyping” at A List Apart by Shawn Medero shows some great examples of paper prototyping.

Another week, another post. I presented this material to the HCI 522 class this week.

A long time ago, in a galaxy far away, I was a technology coordinator for a small, rural K-12 school. I was tasked to organize six high school seniors to create a new school website.

Since the school’s website was to also serve as a community resource, our audience was very broad and ill-defined. We decided to use personas to help us design the website. The following is the process we used to design the website

Step 1: List the types of users

We first created a list of all of the types of users that we thought would visit our site. Our list included user types such as:

• elementary students,
• high school students,
• teachers,
• parents,
• grandparents, and
• school officials.

Step 2: Create a persona to represent each class of users

Next, the students and I wrote one persona for each class of users. A couple examples of our personas follow:

Sally is a 17-year-old senior who likes to hang out with her friends and chat online. She loves taking pictures for the yearbook and never misses a ball game.

Jim is Sally’s dad. He doesn’t trust Sally to drive his new truck to all those ball games she insists on going to, so he drops her off and picks her up at the school for each game. Being a single parent, Jim is also in charge of cooking the meals at home.

The personas that we actually wrote were two or three paragraphs long.

Hidden step

A “hidden step” that I failed to include in the slides is that after writing the personas, we discussed them and fleshed them out a bit. We explored the various goals and values that each of the characters possessed. This lead us into the next step.

Step 3: What features does each character want?

After exploring the goals and values of each character, we were able to tease out the specific website features that would benefit each of them.

Sally goes to the website to find out when that book report is due. She also wants to see the pictures from last night’s game. Oh, and if they’re serving mystery meat tomorrow for lunch, she’s bringing her own.

Jim has to schedule his time off work around Sally’s ball games and visits the website to check the schedule for the upcoming week. Sally harps at him if he fixes the same thing for dinner as she had for lunch, so he checks the day’s lunch menu as well.

Step 4: Tally up the features

Next, we tallied up the number of personas that wanted each feature. This helped us determine which features were most important and which features would be least utilized.

Step 5: Design the website

We used a few guidelines in designing the website, for example:

• Place the most common features on the front page of the site where they are easily found.
• Consider accessibility:
  • The typeface should be large enough (or resizable) so that the grandparents can read the site
  • Since broadband wasn’t available in this area, the site needs to be a small download. Don’t use large images or Flash or require other multimedia extensions/plugins.

The Result

Since most of our personas were interested in the lunch menu, upcoming events, and recent events, we placed those items on the main page of the site. Most of the other features can be found be following the links in the navigation sidebar.

Overall, most people liked the site. There were some features that we didn’t predict, however. One example was that people wanted to check the website to see if school was delayed or canceled do to inclement weather. So on the days that school was delayed or canceled, we added a new red alert box above the upcoming events and lunch menu blocks that alerted the visitor.

References and Resources

• Kevin’s presentation slides (PDF)
• Kevin’s presentation video (Quicktime movie)
• OK/Cancel Jack and Jill comic

This week in Scientific Methods of Human–Computer Interaction (HCI 522), I presented a number of design guidelines from Ellen Isaacs’ and Alan Walendowski’s book Designing from Both Sides of the Screen: How designers and engineers can collaborate to build cooperative technology.

The Guidelines

The guidelines in the book fall under four basic tenets:

• On being a butler
• Don’t impose: respect physical effort
• Don’t impose: respect mental effort
• Be helpful

On being a butler

Software should act like a butler. It should always be available. When asked to do something, it should be prepared to do it with few questions and no complaints. If there is a problem, it should find a way to fix it or work around it without bothering the user. (Also, it should have an English accent.)

Software shouldn’t disturb the user by interrupting and suggesting ways it can be helpful. Instead, it should pay attention to what the user has done in the past and so that it can better anticipate what the user will want in the future. However, software shouldn’t go overboard in anticipating the user’s needs because it is more costly to do something the user doesn’t want than to not take the initiative. Software should be courteous and respectful—even when the user asks the software to do something it can not do.

Don’t impose: Respect physical effort

Treat clicks as sacred. Clicks include mouse clicks, keyboard presses, taps on a touchscreen, button presses on a physical device, and voice commands. Require as few clicks as possible.

Remember where users put things.
Remember everything users do to adjust the application. The next time they come back, everything should be just as they left it.

Remember what they told you. This one’s easy: don’t ask people for the same information more than once. If they update their information, remember the updated information.

Don’t impose: Respect physical effort

Make common tasks visible and hide infrequent tasks. Determine the most common user tasks and make sure they are visible and easily accessible. Hide less common tasks so they don’t clutter the screen and make it more difficult to find the common tasks.

Give feedback and show signs of progress. Acknowledge the user’s request and, if you can’t comply immediately, let them know what you’re up to and how long it will take. If a command can’t be carried out quickly, let users interrupt.

Keep preferences to a minimum—provide smart defaults. Most users never modify the default preferences, so the application’s default behavior is effectively the only behavior.

Be helpful

Offer sufficient information early, in context. Prevent errors. Indicate which information is required, what format is expected, etc. Try to prevent errors whenever possible.

Solve problems—don’t complain or pass the buck. Don’t bother the user with problems you can solve yourself. If you can tell the user how to fix the problem, try fixing it yourself.

Be predictable. Develop a set of conventions to use throughout your application. Users should be able to predict what a feature does based on their knowledge of what the other features do.

Request and offer only relevant information. Don’t mislead. Don’t offer options that are not available. Ask for information only if and when you will use it (and then remember it). Never collect and then ignore sensitive information.

Explain in plain language. Avoid jargon. Don’t blame the user. Indicate the consequences of options.

Discussion and Afterthoughts

Derrick Parkhurst pointed out that many of these guidelines keep popping up in many different books on usability. The guidelines I presented are just a sample of those in the book.

References and Resources

• Kevin’s presentation slides (PDF)
• Kevin’s presentation video (Quicktime movie)
• Designing from Both Sides of the Screen by Ellen Isaacs and Alan Walendowski. ISBN 0-672-32151-3.

The Purpose of Usability Studies

There are a number of reasons why you might want to run usability tests. some people (QuickTime video) run usability tests to certify that a product is (or in this case, isn’t) usable by a test audience. Others may run usability tests to learn when their product is “good enough” to release. But I think the best reason for running usability tests is to learn how to improve your product.

In the first two cases, you will probably want to obtain more quantitative than qualitative results. Would you consider your product usable if more than 50% of the users can perform some task within a certain period of time? What metrics do you choose to determine when to stop “fixing” your product and release it?

But in the third case, the qualitative results will be more abundant than the quantitative results. How can you make the user’s experience more enjoyable? How can you help them feel more productive? While there are quantitative underpinnings in the methods and techniques you can employ to improve the user’s experience, much of the measurement of the experience will be qualitative. This is not a Bad Thing.

Software Development Process

Parkhurst recently presented a slide showing his idea of the development process of an e-commerce website (see below).

I think there are some problems with this process. I propose that there should be Designers between Clients and Developers.

The designers would work with the clients to determine their needs and the needs of the end-users of the product. The designers would also be responsible for determine who the target audience is and would design the product features for that audience.

Specific Counter-arguments

Step 1: Who are your users?

Parkhurst argues that it’s difficult to determine who the users of a product are and that testing the wrong users would prevent you from generalizing the test results to the general audience of the product. I agree with this so far. I disagree, however, in his thinking that this should slow down or prevent usability testing. As I outlined in the software development process above, the audience should have been prior to the developers writing the software—during the design process. By the time you have software written for users to test, you should already know who the target audience is.

Step 2: What if your product functions don’t map onto user needs?

If you’ve got a good handle on your target audience and you’ve designed with them in mind, then this shouldn’t be too big of an issue. Of course, there will be some problems—after all, that’s why we’re doing the testing!

If the product functions don’t map onto the user needs, then we’ve either designed the software incorrectly or programmed it contrary to design specs.

Step 3: There is an inherent conflict between “friends and family” and reality.

This is sometimes (but not always) true. If your friends and family are within your target audience, then they are viable test participants. They may not verbally criticize your software as much as disinterested parties, but you shouldn’t be relying solely (or even primarily) on verbalization. Most users aren’t accustomed to thinking out loud as they use software, so any information you gain from this will be qualitative anyway. The only quantitative information you’ll obtain from the test will be based on the user’s actions.

Step 4: The laboratory setting threatens ecological validity.

True enough. But ecological validity isn’t necessary to the overall validity of the experiment. If it were, then we’d have to throw out most of the quantitative research that we’re basing our design decisions on.

An example: Parkhurst does a lot of work with gaze tracking and gaze detection. Most people don’t sit at home with a gaze tracking strapped to their head. Are the results that Parkhurst obtains from these experiments invalid?

Conclusion

Many of the problems mentioned above should be addressed in the design phase of the project and the solutions should be established well before the user testing phase begins.

Summary

Jakob Nielsen wrote an article titled “Why You Only Need to Test With 5 Users” which
argues that, contrary to popular belief, usability testing need not be expensive and complicated. In an earlier paper, Nielsen and Landauer (1993) showed that testing with just five users will uncover about 85% of the usability problems in a website or software application.

Discussion and Afterthoughts

On the ugliness of Jakob Nielsen’s useit.com website: Nielsen outlines his thoughts and reasoning for his “ugly” site design here: Why This Site Has Almost No Graphics. A few web designers collaborated to redesign his site incorporating graphics.

Take-home Points

Usability testing doesn’t need to be some huge, complicated process—just grab a few people and get started!

References and Resources

• Kevin’s presentation slides
• Kevin’s presentation video (Quicktime movie)
• Nielsen, Jakob. “Why You Only Need to Test With 5 Users,” Alertbox.
• Nielsen, Jakob and Landauer, Thomas K. “A mathematical model of the finding of usability problems,” Proceedings of ACM INTERCHI’93 Conference (Amsterdam, The Netherlands, 24–29 April 1993), pp. 206–213.

Here’s the introduction that Jesse wrote about Project Icarus:

Since the beginning of time humans have watched birds soar through the air and have dreamed of doing the same. However, the laws of physics have conspired to make that dream difficult, if not impossible, for a single human under his or her own power. Fortunately, we are not constrained by physical law in virtual worlds so we can come close to fulfilling this dream for many. Our primary objective for this project is to allow a person to navigate a virtual world as if they are flying by flapping their arms like wings. A secondary objective for this project is to minimize the equipment the user must interacts with in order to experience self-powered flight. Ideally the user will enter a virtual reality CAVE, start the program and fly.

We demonstrated the program to our classmates and won first place in the class competition. The prize was $50 which almost covered the cost of the hardware we had purchased for the project (excluding the camera equipment that I purchased). I posted an excerpt of the video of the poster competition on the Icarus website along with some other videos. Ethan gave a good interview while I stood idly by in the background.

The remaining final project is for my linguistics class. I’m working on a natural language search program that interfaces with the IMDB database. So far it only understands sentences such as “Who starred in Harry Potter?” I’ll be adding more grammar and sentences to it this weekend since I have to demonstrate it for the instructor on Monday.

And if finishing that project wasn’t enough, I need to write a bunch of code to improve the wheat combine simulator because some John Deere people are coming by on Tuesday to see what we’ve got so far. That’s right—Tuesday of finals week! Can they have worse timing?

To bed now… I’m going to have a work-filled day tomorrow—er, later this morning.

Our presentation can be downloaded from here.

I still need to work on the design of the page, of course (pretty it up). I’d also like to try to do some clustering—folding all the near-same stories into one entry. That way, you don’t read the same story three times.