A Product Model: Amazon Kindle eReader OOBE

The product:
An entirely new out-of-box-experience (OOBE) for an existing product line.

The problem:
Original requirements did not identify crucial use cases.

The Kindle UX team used a product model to:

  1. Identify critical, overlooked requirements and integrate them into the product definition in time to actually work on them.

  2. Unblock developers prior to the delivery of final screens.

  3. Define every functional element on final screens.

VIEW ENTIRE SPEC▸

Background

From 2010 to 2012 I was in charge of Amazon Kindle eReader UX design for three device generations: the first Kindle without a hardware keyboard, the first high-resolution Kindle, and the first backlit Kindle (the Kindle Paperwhite). My team tackled both the design of new features as well as adapting existing features to meet new business requirements.

For example, Amazon Kindles originally shipped entirely pre-configured—the user opened the box, turned on the device (it was pre-charged) which would then seamlessly log on to any compatible 3G data network (Amazon paid all data costs and no user sign up was required) and then log in to the user’s Kindle account.

It was a terrific, almost magical, user experience. But to reduce costs [1] Product Management decided that:

  1. New Kindles would not be pre-configured. This simplified distribution and allowed any Kindle to be sent to anyone.

  2. A new (i.e. cheaper) Kindle would be introduced with no data connectivity, only Wi-Fi.

  3. The user would have to manually enter their Amazon account information or create a new Amazon account [2] during OOBE.

  4. And—if there was no data option—the user had to enter Wi-Fi network settings during OOBE.

“When can you get us some screens?”

Product Management and Development delivered their requirements to the Design team and asked when they could get screens. Given the changes to OOBE I thought the requirements were a bit on the thin side. I asked my design lead to create a flowchart—a product model—of the new OOBE instead of jumping right to screens.

Product Model 101: Describing the happy path (and nothing but the happy path)

The product model revealed that Product Management and Development requirements described a single, best case, “happy path”.

The Kindle OOBE “happy path” requirements described a simple, error-free experience which assumed a successful data network log on. There were no details about on-device account creation (ODAC).

Real-world requirements (i.e. error states)

The “happy path” scenario did not include any error states. They weren’t hard to identify—I just assumed something could go wrong at each step in the “happy path” scenario to wit:

  1. The inability to connect to a data network.

  2. The inability to connect to a Wi-Fi network as a fallback option or as the primary option in the case of less-expensive Kindles without data capabilities.

  3. Error states when logging in to an existing account (incorrect/forgotten password, username, etc.).

  4. Specific steps and error states in the on-device account creation (ODAC [3]) process.

I updated the product model accordingly, reframing networking error states as “Welcome” use cases.

The Kindle OOBE product model now included extensive error handling, er, “Welcome” use cases.

Design identified these use cases in the same amount of time it would have taken to produce a set of screens for the “happy path” scenario. This wasn’t scope creep—these were essential aspects of any new OOBE. The product team was able to adjust development schedules and resources accordingly because these use cases were identified early enough.

User advocacy

Product Management and Development pushed back had against these findings. I remember one developer asking how it was possible to not be able to join a data or Wi-Fi network. I reminded this person that it was entirely possible to receive the Kindle as, say, a Christmas gift. And the user is at Grandma’s house. Which is in the boondocks. Where’s there’s no 3G coverage. And Grandma (back in 2010) didn’t have Wi-Fi.

Development unblocked: Who needs screens?

Note how the Welcome and Register use cases had very similar flows. In each, the user had to first identify a target (e.g. a network or account) and then provide proper credentials (e.g. username and password). This meant that each flow required:

  1. Introductory screens with options (setup now or later).

  2. Selection dialogs to specify a network or account type.

  3. Password and username entry and validation.

  4. Error handling (invalid username and password).

Which meant Development was unblocked.

These were all common, well-understood interactions with plenty of existing online examples that could serve as the basis for scoping and backend integration. Development could implement all of these use cases without the need for final screen designs. Development could create the necessary screens and use functional placeholder elements (e.g. text fields which could accept data, buttons to submit, approve, or cancel a process, etc.).

Final screen designs would add, at most, non-functional elements such as user instructions (text strings) and look-and-feel specifics (layout, colors, iconography, and the like), all of which would be low-risk additions at later phases of development.

ODAC details

Design worked with Product Management and Development to identify the specific steps and requirements of the new ODAC process. Instead of delivering screens, Design repeatedly updated the OOBE product model to document decisions and detailed requirements. This was faster and still provided Development with all the information they required to complete work on ODAC.

The product team identified five key steps in the ODAC process.

  1. Choose country

  2. Account info

  3. Payment method

  4. Billing address

  5. Completion

I added them to the product model.

Details, details, details

The product team then plotted a detailed flow and identified the data fields and specific actions required on each screen.

Final screens virtually design themselves

The Kindle UX design system specified screen layouts, typography, button layouts, graphics, and the like.  

Thanks to the detailed screen requirements, developers following the Kindle UX design system could almost create final screens themselves. Design provided explanatory content, field labels, button names, and the like.

Summary

Of course, some design problems are simple enough and sufficiently well understood that there’s no need to resort to a model prior to delivering screens. That wasn’t the case with the Kindle OOBE.

By beginning with a product model instead of screens I was able to identify overlooked use cases in time to accommodate the increased product scope. By documenting product decisions within the product model it eventually became so detailed that final screens were pre-defined before they were actually designed and delivered as pixel-perfect graphics with edited and approved text.

The process was not initially accepted by the entire product team—design by screen was so deeply engrained in the culture that it was difficult at first to understand how using a product model would actually speed decision making and eventual screen design.

1 A phenomenon now known as "enshittification".

2 This was back in the days when, believe it or not, not everyone had an Amazon account. This allowed people to gift Kindles to anyone, regardless of whether they had an existing Amazon account.

3 ODAC is a common and well-understood part of using online services nowadays. However, it was still somewhat unfamiliar to many users fifteen-odd years ago.