Database Reference
In-Depth Information
War Story 1: Honey, I Shrunk the Functionality
This case involved a revision to an existing software product, so there was a large body of underlying
code already in place. The team had been working very hard on some new functionality, and it was a
focus of the usability test tasks we'd created. But 2 days before the first usability test, the latest build
was so unstable that we had to drop back to a previous build that lacked the new functionality. That
version was buggy as well, causing delays in the usability tests when the system behaved strangely or
crashed. Because customers were coming from out of town to participate in the tests, we didn't want to
inconvenience them by rescheduling. The tests still provided useful information, but the team was
conscious of how much more they would have learned if they had had all their new functionality ready in
time.
War Story 2: Ready, Fire, Aim
We'd successfully conducted three usability tests of an e-commerce site running off the company's
development server. The planned launch was a month away, and development was proceeding at a
feverish pace. Right before the fourth test, someone accidentally uploaded the wrong thing and wiped
out the most recent 3 days' worth of work from the entire team. That was the end of that usability
study—with so little time available and a snafu on top of it, no further usability tests could be scheduled.
We were just glad we'd managed to conduct three tests before it happened.
War Story 3: It's Coming (and so Is Christmas)
Another prelaunch Web site. Development was being done by an outside company who didn't like to
announce every little schedule slip, especially because they'd been working long hours to meet an
aggressive launch date. At 6 pm the evening before the first day of testing, the team finally admitted
that they weren't going to be ready. Testing was postponed from a Thursday to the following Tuesday.
Six participants had to be rescheduled. Not all of them could attend the new date, so replacements had
to be recruited on a tight schedule. (And even when things can be pulled together in time, it can be
harrowing—my record for the closest I've gotten to usability testing before seeing the interface for the
first time is 2 hours. Hearing a developer ask, "What time does the first test start?" is never a good
sign!)
War Story 4: Network = Not Work
In this case, the problem wasn't with the Web site we were testing but with the network connection in
the room we were using as a temporary usability lab. Right before the first test, the network became a
"not-work." I spent the first half hour of our test session chatting with the user while several people
wrestled with intransigent cables and hardware. When they were ultimately unsuccessful, we moved
the test to the development manager's office. Only three observers could fit in the office—half the
number that had wanted to attend the test. The really frustrating thing about this case was that, being
somewhat paranoid about hardware, I had insisted on a thorough test run the day before and
everything had worked flawlessly.
Search WWH ::




Custom Search