Last week I wrote about something I learned from Brad Stone’s The Everything Store, a history of Amazon.com. It’s enlightening to read about the genesis and evolution of one of the most important information environments in the world. Here I’ll share another insightful anecdote from the book, which has to do with the design of the first Kindle.
Kindle is much more than a product; it’s an ecosystem. The product wouldn’t have succeeded if enough of that ecosystem weren’t built out at launch. It wasn’t enough that the team delivered a beautiful, useful, usable reading device; many other pieces needed to be in place on day one. For example, there had to be e-books available for the device. Amazon CEO Jeff Bezos set a target: 100,000 titles for launch. His team had to convince publishers to convert and offer their books to a new format.
Customers also needed a way to get those books onto their devices. The obvious precedent was the iPod/iTunes/iTunes Store ecosystem, which required that users connect their devices to a computer where they’d purchase and download music files. Because of that decision, the iPod could be simpler since it didn’t need a built-in communication stack.
However, this also made the process more complicated for users, since it required that they have access to a computer and know how to set the whole thing up. As always with design, it was a tradeoff. Mr. Bezos wanted Kindle users to bypass this complexity by buying and downloading books from the device itself.
Amazon hired Pentagram to design the device, and the designers were having trouble with these requirements. Having customers easily buy and download books from the device implied having a cellular radio inside each unit. This radio and its required wireless plan would affect the product’s financial viability. It was hard for the designers to see past the implications:
The Pentagram designers couldn’t understand how the economics of the wireless connection could work and assumed Amazon would be asking the user to pay a wireless charge every time he or she bought a book. At one point, they pitched Bezos on a process similar to the iTunes model, which required making the bookstore accessible on a PC. Bezos pushed back. “Here’s my scenario, I’m going to the airport. I need a book to read. I want to enter it into the device and download it right there from my car.”
“But you can’t do that,” [Pentagram designer Tom] Hobbs replied.
“I’ll decide what I can do,” Bezos said. “I’ll figure this out and it is not going to be a business model you understand. You are the designers, I want you to design this and I’ll think about the business model.”
What Mr. Bezos is implying here is that the designer doesn’t have access to the full picture. The expectation is that the designer will work on just one element of the ecosystem: the device. He must trust that the other key elements will be there. The product’s business model — perhaps its most important aspect — is specifically called out as being out of bounds for the design team.
This story illustrates a particular understanding of design’s role in the process, one which is common in the business world: That designers are there to help give the artifact form, to make it usable, beautiful, engaging, etc. They’re not there to find out what the thing will be, just how it will be. This perspective is a missed opportunity; designers are well-suited to answering such questions before large amounts of money are sunk into the effort.
Kindle is a successful product-service ecosystem today in part due to those critical early decisions. But I remember seeing that original Kindle for the first time; it was idiosyncratic and polarizing. As a Sony Reader owner at the time, I was surprised at how clunky, awkward, and over-specified the first Kindle looked. It seemed like a prototype, and in hindsight, it probably was.
Eventually, the Kindle evolved towards something much simpler and appealing, something more “designerly.” (I’m reading The Anything Store on my Kindle Oasis, which is great.) I can’t help but wonder if the product wouldn’t have gotten there sooner had the designers and client found a way to collaborate more strategically.
But designers can’t serve this strategic role without a relationship of trust with the client. Trust works both ways: the designer must trust that the client knows what he or she is doing, and the client must trust that the designer can grok the domain in ways that increase (rather than resist) forward motion. This anecdote strikes me as an example of the absence of such a trusting relationship.