Archive for October, 2007

In usability utopia, when developing or redesigning a site you get to:

  • plan
  • analyze
  • design, and
  • test.

Then when you’re testing you get to test, refine, test, and refine until you get the site to an acceptable level of usability.

In the real world, you’re sipping an over priced coffee watching videos on YouTube when you get a call from a web site owner. The call usually goes something like:
“Hey Mike, do you have some time run usability testing on a site that I’m developing?”
“Uhm, I’m in the middle of something right now, when are you thinking?”
“Well the site launches in two weeks and we just wanted to make sure we are on the right track.”

After I throw my headset across the room, I calm down and ask for a meeting so I can find out the site owner’s hope and dreams. Well, not really. I’m looking for some insight so I can effectively create a usability test that will produce the information I need to help make the site better.

This is what I call the sit down which I usually hold in a small out of the way Italian trattoria where I can hide the gun in the washroom — sorry having a Godfather moment there.

So no trattoria, just a meeting where I ask a bunch of the following questions:

1.  Purpose

  • What is the purpose of the site?
  • What are the goals of the site?

2.  Site goals

  • Describe your site?
    • From an organization’s viewpoint?
    • From a user’s viewpoint?
  • Define a successful site? 

3.  The audience

  • Who are your users?
  • Describe your users? (Age, experience, education)
  • Why will these users come to your site?
  • When and where will users access the site?
  • How will users access the site?

4.  Tasks

  • What will users do on the site? (User tasks, content, features and functionality)
  • Which tasks are critical to the users’ success on the site?
  • Which tasks are most important to users?
  • Which features will users use the most?
  • Which features are prone to usability issues?
  • Which tasks are critical your company’s success?
  • What will compel users to return to your web site?

5.  Measuring the usability objectives

  • Which tasks should users be able to accomplish easily with few errors?
  • Which tasks should users be able to finish quickly and efficiently?
  • What level of satisfaction should users have after using the site?   

6.  Accessibility

  • What accessibility testing have you done?
  • What accessibility tools are you using?
  • Who is your accessibility contact?

Ever been in a meeting where someone blurts out some lame idea and then when everyone looks at them like they are crazy the person says “Oh, I was just thinking out loud”.

My first reaction is, “Che, thinking out loud, you were talking because if you were thinking, you wouldn’t have said anything”.

Thinking out loud is bad in meetings, but it is essential for usability testing.

What is thinking out loud process?
During user testing some of the most valuable information you can get is from what people are thinking. The hard part is getting those uncensored thoughts. Participants are in an uncomfortable position as they are stuck in front of computer with a facilitator and note taker looking over their shoulders.

I try to get participants to open up by saying “We are not only going to be observing you, but we need to know what you’re thinking. Don’t censor yourself. I was not part of the development team (even if I was) so you’re not going to hurt my feelings. If you think the feature is good, let me know, if you think it’s terrible, let me know that also”.

If you get someone like me who can’t problem solve and talk at the same time, it’s time to earn your keep. You need to go into your facilitator bag-o-tricks to get the participant talking and keep them talking.

The key to keep a participant talking is to continually prompt them throughout the test. Try some of these techniques next time you have a participant who is not talking.

Staying neutral

  • Stay neutral by not:
    • sharing your thoughts about the web site
    • showing facial expressions or changing your tone to show that you agree or disagree with the participants comments
  • Don’t influence the participant, or offer interpretations. For example, if the participant says, “I’m not sure what to do here,” don’t say, “So are you confused because the menu bar is unclear?”
  • Don’t ask subjective questions such as “Do you like that tab?”. Instead ask “Did that tab help you reach your goal?”
  • Don’t be too quick to assume that the user is lost or having a problem.
    If it appears that the participant is having trouble and is not talking don’t ask, “Are you have trouble with this task?,” but ask, “What are you thinking you should do here?”

Keep them talking by asking questions

  • What is your goal here?
  • What did you expect to happen when you did that?
  • How did you expect that to work?
  • Is that what you expected to happen?
  • Can you tell me what you were thinking?
  • What do you want to accomplish here?
  • Describe the steps you are going through here.
  • How did you feel about that process?
  • Tell me about your thinking here.
  • Were you happy with that transaction?

Summarizing key actions in the test

  • When you notice something that is key to understanding the participant’s thoughts, summarize the event. Often the participants offer more detail about their thought process.

Not really my area of expertise but an important piece of the development puzzle is web site accessibility.

The lawsuit
The National Federation of the Blind filed a lawsuit against Target Corp (TGT) in U.S. court claiming that Target did not provide an accessible web site to people with visual impairments.

A federal judge then granted class-action status to the lawsuit alleging that Target Corp. (TGT) is breaking California and federal law by making its web site unusable for the blind.

Further to this, California may require web sites to be accessible to visually impaired users and this requirement could extend to all U.S. states under the Americans with Disabilities Act.

Existing law
Already implemented in the U.S. is Section 508 of the Rehabilitation Act. This section requires Federal agencies to make their electronic and information technology accessible to people with disabilities.

Currently, there are no laws in Canada that explicitly require web sites to comply with accessibility standards. There are, however, some statutes that impose obligations on the Federal government, federally regulated bodies and provincially regulated bodies, to make their web sites accessible to people with disabilities.

The Federal Government of Canada, through the Treasury Board, has implemented Common Look and Feel (CLF) standards for all Government of Canada websites. CLF uses the W3C standards to ensure that Government of Canada sites are accessible to as many users as possible.

Taking steps towards accessibility
Start taking steps towards making your site accessible. With the accessibility requirement already law for both U.S. and Canadian government agencies, it is only a matter of time before this requirement is extended to privately owned sites. 

In addition, it not only makes good business sense, but it will improve your web site not only for visually impaired users, but it will also benefit users without impairments.

To see how accessibility changes the lives of people with impairments, check out these videos.

A valuable resource to learn more about accessibility is the World Wide Consortium (W3C). Started by the dude who created the internet, the W3C creates web standards and guidelines. Check out the W3C Accessibility guidelines and tools section for more information on accessibility.