Skip to main content
Kindle Love

My Kindle sucks, but I love it


Why clear priorities are at the core of great product design

The Kindle Paperwhite, one of my most-used and most-loved possessions, is a creaky plastic rectangle with an ancient-looking black and white display. As a device, it’s far removed from the sexy, exciting world of tech product design, and for a company that’s trying to make delivery drones an actual thing, you’d be forgiven for expecting something a little more advanced. Every iteration of the Kindle has been basic, understated, and (some might say) boring. Even reading, its main function, is a bit crappy. Turning the page causes the entire screen to blink in and out of existence, just like when you’re reading a real book and you drop it down the stairs.

The software is simplistic; relatively easy to use, sure, but not the most consistent. As a product, it’s not exactly sexy or thrilling. The first time I saw a friend using a Kindle I thought: “Wow, that looks like a piece of shit.”

But as soon as I started reading my first book on a Kindle, all of these criticisms turned out to not matter at all.

The Kindle is an example of a product that thrives on technological and budgetary constrains.

Here’s the thing about the Kindle: it works. When you read a book on it, the hardware and software disappear. The content itself becomes the only thing. This is a product doing exactly what it’s supposed to do, and doing it without a fuss, without begging for my attention. Unlike those needy delivery drones, pestering people for signatures…

The Kindle is an example of a product that thrives on technological and budgetary constrains. This forces its designers to keep their priorities straight and their focus sharp.

Could it have more features, maybe a super high resolution display? Sure, but that would make it more expensive right now. It’s competing against books, the price point can’t be too high.

Could it be thinner and lighter? I guess, but is the size really that much of a problem for you?

Could it have a colour display? Yes, but battery life is far more important, and yet again, the price.

Could there be a headphone jack for some reason? Yeah… but it’s for reading books.

Could there be an easier way to share a passage on Facebook? Yes, but stop… go away.

To get into the head of a Kindle designer, here’s an example of what the top priorities for the original model could have looked like:

Amazon Kindle Product Design Priorities

The original Kindle didn’t have a light because it wasn’t crucial to the core experience. You could still perform the necessary functions without it — a light wasn’t a “must-have”.

The must-haves are use cases that absolutely must be fulfilled for the product to exist. Once the product satisfies these use cases, designers can get generous and start exploring more specific optional use cases.

Amazon Kindle Product Design Priorities 2

Once the core reading experience of the original Kindle was established and proven, the designers added a light to improve the experience and meet additional use cases.

Packing a product with features often just wastes money and time…

Trade-offs and compromises are at the heart of every product design process. Some companies are very good at focusing on the core experience of a product (see Amazon, Apple). These are the companies that understand that a product doesn’t need to do everything, please everyone, all in one go. They add features and improve the product iteratively: after the core experience of the product has been established.

However, a lot of companies struggle to prioritise. They fail to understand what they’re really trying to do and muddy the waters with too many features before they’ve proven the main use cases. Packing a product with features often just wastes money and time on things that are unrelated to the core experience. This means they go to market a lot later than they should, with a product that probably costs a lot more than it should, with features that most customers will never even use.

You’re making a product? Great. But do yourself a favour and think: What are the core essentials of it? What are the must-haves and what are the nice-to-haves? Is it really that bad if some of the non-essentials are left out until a later iteration?

(Answer: No.)



UX Mailing List ONE