Week 5 Reading

In chapter eight, we learn that most arguments are a waste of time. Duh. But also it lets us know how to avoid them. Most web design teams spend a lot of time rehashing the same issues over and over. This is because what we like as web users always differs from other users. If we believe everyone is like us, it will create a gridlock in any web design meeting. Instead of trying to find something that everyone likes, the group usually will try to determine what most users like to figure out the persona of the average web user. The problem is, there is not average user. Instead of asking questions like "do most people like pulldown menus?" you should ask "does this pulldown menu with these items, etc. work for people who are most likely going to use this site?" You have to think creatively as a group in order to answer these questions and come up with a solution that fits.

Chapter nine discusses usability testing (I just wrote tasting, that sounds more fun). The important thing to remember is that focus groups is not usability testing. In a focus group, people sit around a table and react to ideas. Usability testing is on user at a time being shown something and asked to figure it out or do a typical task. Testing one user is 100% better than testing none. The point of testing is to inform your judgement. You're trying to make improvements to your site, not to prove that it works somehow. Testing provides invaluable input which will make it easier to choose with greater confidence. It's not something you do once. You must test, fix and test again.

An ideal number of testers is three to four people per round. The first three are likely to encounter nearly all the problems and using three users helps ensure you will definitely do another round. A lower number of users allows you time to test and debrief on the same day in order to fix the problems quicker.

It's important to review the results right away do decide what to do next. First you must review the problems and decide which ones should be fixed, then problem solve and figure out how to fix them. When fixing the problems, try to solve anything new and remove any surprises. It's important to give your group plenty of time to test and fix so at least a month ahead of the release date is good to start testing.

This is the perfect web design team:
http://www.myintervals.com/blog/2008/03/10/how-to-assemble-a-web-design-team-based-on-the-a-team/

A simple problem solving article:
http://webdesign.about.com/od/webdesignbasics/a/aa062007.htm

Twelve tips for team building:
http://humanresources.about.com/od/involvementteams/a/twelve_tip_team.htm