Think twice before copying Amazon: peeking under the surface of a user interface design

When creating eCommerce and other online applications, questions of UI design are often at the forefront of most requirements discussions. One of the most common pieces of input we hear is why don’t we just “do it like Amazon” (or “Google” or “name your favorite big-name site).  The reality is, copying what you see on the surface of Amazon is risky business. There is much more to Amazon than meets the eye. Before you copy, dig deeper into the business rules and understand if and why a feature works for Amazon.

A few weeks back, I attended a presentation by Jared Spool of User Interface Engineering presenting some of the detailed usability research they’ve done into the behemoth that is Amazon. He offered up the following insights about why Amazon works. I think they might help you take your requirements discovery with the would-be Amazon copier to the next level.

Do you have the traffic that Amazon has?

When you get the hits that Amazon gets every day (in excess of 71 million visitors in December of 2008) you can experiment in ways that others cannot. You can turn on a feature for a minute or two, track the results of thousands of visits, turn the feature back off, and take some time to evaluate the results. With an average 8 million visitors a day, you can expect a meaningful subset of people to use any given feature. Even 1% of visitors can generate significant momentum.

So consider, how much does an idea depend on traffic volume? If you don’t have it, what are your alternatives?

Will your content be engaging?

One of Amazon’s most valuable features is the reviews and many sites try to copy this feature, often with lackluster results. On average, 1 in 1300 people who buy a product will write a  review. Target licensed Amazon’s entire eCommerce platform yet has failed to produce Amazon-like results because Amazon’s content and community (and traffic) have more power than it’s technology.

But there is more to reviews than a cool feature combined with high traffic stats. Amazon moderates all reviews to ensure they are on topic. It also provides a feature for people to vote on the most helpful positive and negative reviews. Rating helps keep the best reviews in front of the most visitors, keeping the feature valuable in a way that a reverse chronological sort simply is not.

Better questions to ask for your site might be: How can we encourage people to come back to our site and leave reviews about their positive experiences? How can we help people write engaging stories about our products? What kind of recognition would our visitors want for leaving a review? How can we ensure the review content is valuable to our visitors?

User testing on a micro-scale drives website changes

Amazon is constantly reinventing itself. On any given day, Amazon is trying out 30 new features on a microscale in a production environment. There is an entire team of people dedicated to scheduling them out so there are no conflicts (imagine the maturity of their configuration management practices!). Because Amazon is always testing something new and has the traffic to obtain meaningful feedback on it’s changes, it can take the small, informative risks that create the next best thing for their business.

Some good questions to ask might be: How can we test an idea and get meaningful feedback on it’s viability? How can we obtain a better understanding of how our customers might actually want to use this feature? What’s the smallest piece of functionality we could release and get feedback on? (Agile pundits should love this one.)

Some features on Amazon don’t work as expected

There are aspects of the site that Amazon has been experimenting with for years and just don’t provide the return expected. The Gold Box is a  great example. The Gold Box started as a way to promote alternative product lines, failed, and has reinvented itself a few times. It still fails as a compelling feature that drives revenue. Tags, when you look at them closely, have questionable value and actually support a lot of negative anti-purchasing behavior. Why copy what hasn’t even been perfected yet?

Consider asking: What specific features would you like to copy from Amazon? Why do you feel they would work on this site? And when the requirements stakeholder inevitably says “all of them because they work for Amazon” ask about the Gold Box or show the results for items tagged with “negative” and “junk”.

Product features support a business plan

Amazon could sell products at cost and still make money. It turns over items so quickly that it sells them before the payment is due to the vendor. In that intermediary period Amazon collects interest on the difference. This is why they offer free shipping and undersell competition. Understanding the business is key to designing the product.

Does your design team understand your business plan well enough to build the right features supporting it?

Amazon fails at many small-scale use cases

Surprisingly, Amazon does not handle every use case or visitor goal well. Amazon is great when you know what you are looking for by title or can help you to leverage serendipity to help you try new things based on purchasing patterns. It is not so good and helping you slice through content in specific ways. For example, it is difficult to find the first book by Tom Clancy featuring Jack Ryan or novels written by Nobel Prize for literature winners or the top picks within salsa music. If you are trying to serve a niche and you simply copy Amazon, you might miss out on some valuable opportunities to serve your visitors.

Ask: How do our visitors want to search for content? What unique feature can we offer to serve our specific niche?

***

Is this enough to help you rethink the desire to copy Amazon or push back on the inevitable Amazon-wannabe? Any stories from the field about copying a big player?

Related posts:

1. Bridging the Gap now available on Amazon’s Kindle
2. How to create a user interface specification
3. Defining the scope of an epic before listing user stories in an agile product backlog