| Someone, once told me, "The only way to understand user behavior is
to let them behave." Damned if I can find the exact quote, but I think
it was either a Yahoo engineer or one of the web gurus at 37Signals,
whom I know are big believers in the concept.
At any rate, the point was that you can reason out your use cases
and run usability tests, but until you let a large number of people
beat up on your application, you never know quite what they're going to
do. Sooner or later, they will wander down some dark alley of your
application and click some combination of buttons or enter some data
that you never expected, and because of it wasn't anticipated in your
programming the results may be unexpected. So it's better to get
started on that process sooner rather than later, even if your
application isn't quite ready for prime time.
It's easier to apply this principle on the web than in the world of
boxed software, given that you can provide a continuous stream of
updates to your early users, perhaps giving them fair warning by
calling the application "beta." (I just double checked, and yes, that
word "beta" is still displayed on the logo for Gmail, as it has been
since 2004.) But even assuming you start with a beta and then move on
to an official release, you may have something that works for most
people most of the time, maybe 99% of the time.
But then there's that other 1% where someone does something strange.
I'm thinking of an application I created for taking RSVPs over the
web for a business networking group. It's been live for over three
years, going through many iterations as we added features like online
payments for events, but it still surprises me sometimes. Part of that
is, I admit, because of a lack of testing - certainly no budget for
formal usability reviews - but some of it is because certain user
behaviors take longer to show up.
For example, RSVP form asks the user to enter his or her information
and then provides the opportunity to create a guest list. One of my
design assumptions (and it's the assumptions that kill you) was that
the person filling out the form would be attending as the host of the
party.
But then came the day when it was the administrative assistant in
someone's office filling out the form. She put in her own name and
email address up top, so that she would get the RSVP confirmation. But
she would not be attending. She filled in the names of her "guests,"
the people in the office who would be the actual attendees, and clicked
"Submit." But she was paying close enough attention to see that the
total amount we wanted to charge her was wrong because we were counting
her as part of the party. So now she tried to update her RSVP, changing
her own answer from Yes to No, but leaving the name of the guests. The
website told her "thanks for letting us know" that she wasn't coming
but didn't give her a new total or an opportunity to pay. So she had to yelp for help, and I had to manually correct the database records.
As far as I know, this has only come up once in three years, but
still I really ought to go back and retool the app to make sure it
takes this usage scenario into account.
Certainly, this represents a failure of imagination on my part. I
never anticipated someone would use the application that way. I wonder
if I would have caught it, even with the benefit of more formal
testing.
If anyone has tips on how to expect the unexpected and predict the unpredictable, write me at david@carrcommunications.com
Only registered users can write comments.
Please login or register. |
