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 solution:
The Kindle UX team used a product model to:
Identify critical, overlooked requirements and integrate them into the product definition in time to actually work on them.
Unblock developers prior to the delivery of final screens.
Define every functional element on final screens.
Background
From 2010 to 2012 I was in charge of the Amazon Kindle eReader UX design. I designed and delivered three Kindle 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:
New Kindles would not be pre-configured. This simplified distribution and allowed any Kindle to be sent to anyone.
A new (i.e. cheaper) Kindle would be introduced with no data connectivity, only Wi-Fi.
The user would have to manually enter their Amazon account information or create a new Amazon account [2] during OOBE.
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 requirements for 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:
The inability to connect to a data network.
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.
Error states when logging in to an existing account (incorrect/forgotten password, username, etc.).
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, aka “Welcome”, use cases.
This wasn’t scope creep—these use cases were essential aspects of the new OOBE. But they would have gone unrecognized for much longer had the Design team immediately started developing screens for the “happy path.”
Product Management and Development pushed back hard 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 while visiting Grandma. And Grandma’s house is in the boondocks. Where’s there’s no 3G coverage. And Grandma (back in 2010) doesn’t have Wi-Fi.
The product team was able to adjust development schedules and resources accordingly because these use cases were identified early. .
Networking details (and Development unblocked)
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:
Introductory screens with options (setup now or later).
Selection dialogs to specify a network or account type.
Password and username entry and validation.
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.) without worrying about pixel-perfect layout, exact labels and terminology, or instructional graphics.
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 in later phases of development.
ODAC details (and Development unblocked)
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 requirements. This was faster and still provided Development with all the information they required to create a working ODAC process.
The product team identified five key steps in the ODAC process.
Choose country
Account info
Payment method
Billing address
Completion
I added them to the right side product model after networking setup:
Details, details, details
The Design team then modeled a detailed ODAC flow and identified the data fields and specific actions required on each screen:
Final screens virtually design themselves
Thanks to the detailed screen requirements, developers following the Kindle UX design system could almost create final screens themselves. Design provided the necessary explanatory content, field labels, button names, and the like.
Summary
Of course, many 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 Product Management and Development. 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 the delivery of final screen designs.
[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. On-device account creation allowed people to gift Kindles to people who didn't yet have existing Amazon accounts.
[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.