Case Studies - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 31

Binding Offer, Trust, and Credibility
One of the big questions for Priceline was whether people would understand the concept of the binding
offer—that by submitting a credit card they were committing to purchasing a ticket if Priceline found a
suitable one that an airline was willing to sell.
The results were interesting. There were indeed problems, but not in the way we expected. On the plus
side, the test participants did understand the nature of the binding offer and indicated that they'd be
willing to make purchases this way if the deal was attractive enough. However, giving their credit card
to an unknown Web site was quite another matter. As one user said, "Anyone can put up a Web site.
How do I know these guys are legitimate?"
So we had to think of ways in which an unknown Web site (and company) could convey its credibility. In
the testing, the users told us that seeing real flight information would help convince them that this site
had a legitimate relationship with the airlines. Unfortunately, users sometimes want things they can't
have. Priceline wasn't able to show a list of flights, but they realized they needed to do something. For
example, even the relatively simple idea of including some company information, such as their office
address, the names of company officers, and a toll-free number, helped reassure users that this was a
real company (that they could then research further using conventional methods such as calling the
Better Business Bureau, which a couple of users said they'd do). And in their help topics, Priceline
explicitly says that they don't show flights, which may not be ideal to users but at least prevents them
from looking for information that doesn't exist.
Ultimately, Priceline also launched an extensive advertising campaign featuring actor William Shatner
that helped establish their brand in the minds of American consumers. I'd be very surprised if they still
had the "Are these guys legitimate?" problem today (although they might face it all over again if they
expanded internationally).
3-Day Response—Not!
There were significant technical challenges in matching the user's offer against the airlines' databases
to see which ones would accept. The developers weren't sure how long it would take to query all the
databases and respond to the user. In the paper prototype, we told users that they'd have an answer
within 3 days. We quickly learned that this was unacceptable. If people couldn't know right away, they
wouldn't use Priceline.
This wasn't good news to the product team because this requirement was much stricter than they'd
hoped, and now they had a harder problem to solve. Fortunately, they were able to beef up their
technology and the site now promises an answer within 15 minutes. However, in the absence of data
about what was acceptable to people, the site might have launched with the 3-day reply and failed
miserably.
Probability and Pricing
Initially, the designers wanted to estimate the probability of getting a ticket based on the user's bid. For
example, for a $300 bid, there's a 50% chance an airline will accept. A nice idea, but pretty darn difficult
to do with any degree of accuracy. Fortunately, after hearing all the users describe the ways in which
they currently searched for the best travel deals, it was clear that most people would do their own
research on lowest available fares and base their offer on that. End of problem. The developers could
safely ignore this challenge instead of solving it. (Last I checked, the site simply says, "Visit other travel
websites to research the fares and itineraries available on your travel dates.")
Frequently Asked Questions
One of the Catch-22s of new Web sites is figuring out what the "frequently asked" questions are going
to be for a site that hasn't launched yet. But this is exactly what we were able to do. A useful output of
the paper prototype tests was the set of questions that people had about how Priceline worked. For
example, "Is there a fee for this service?" (The answer was no, but the site didn't say so.) Whenever a
user had a question, we'd give them an answer orally, then jot down both the question and the answer