Initial Problem

No unified preference authority existed. Typically, businesses collect, store, consume, and manage their preferences internally. The exception is the 1-Click preference which is shared between businesses. Since these businesses wholly own the storage of the preference it is impossible to view or display a customer’s preferences in a single location. When an issue occurs with a customer’s purchase information (e.g. an expired or lost card, a new home address, etc.) the customer must identify on their own what preferences exist across Amazon, locate those individual management pages, and manually update the preference.

This process is arduous and many preferences are overlooked causing purchase failures across the site, customer headache, and millions in lost revenue.

Goals

• Identify the existing problems associated with purchase preferences.
• Understand the needs of businesses that use these preferences.
• Understand the customer position of being a cross-business shopper.
• Understand the lifecycle of the preference and the customer journey from low to high engagement.
• Understand preferences as an ecosystem that has impact in aggregate.
• Simplify the experience for customers while not inhibiting their behavior.
• Propose a new system that provides transparency and ease of management that can grow to meet customer needs throughout their customer journey.

Discovery Phase

Discovery existed on three dimensions:

1. Understanding the existing preference and lifecycle
2. Existing customer problems and needs
3. Business requirements for teams that use preferences

Preference Discovery

The only way to understand how preferences work broadly was to do an audit of the site. I analyzed each major business and how they used preferences. I discovered two main preference types with different contexts and requirements. The lifecycle of both were very similar.

Types of Purchase Preferences

Purchase preferences can be loosely divided into two categories.

Customer Present (CP) purchase preferences are convenience shortcuts to allow purchases to be made more quickly.
 

• Includes both 1-Click purchases and cart purchase defaults that prepopulate checkout and notions of default payment methods and addresses.
• The purchase context can be known at the point the preference is used and the customer is available to respond to conditions that arise.
• The customer can decide which context fits the purchase at hand and choose a preference that suits that context if multiple preferences are available.

Customer Not Present (CNP) purchase preferences are used to charge orders in the future and are future looking in nature.
 

• Includes subscription businesses like Prime, Subscribe and Save, Periodicals, etc.
• Customers are not available at the time of charge so errors must be handled out of band through emails and site messaging.
• Future looking language like “when available” must be used due to the fluctuating nature of balance instruments.
• Tend to have more precise eligibility requirements and are tailored to the acting business or product.
• May also include additional data like recurrence.

The Lifecycle of a Preference

Preferences exist in four main contexts and UI is generally built around these areas.
 

1. Creation. Preferences are generally created at the time of purchase as an artifact of purchase choices. These choices are then saved to a preference store. UI here is typically low or non-existent to avoid purchase friction.
2. Consumption. When using a preference for a CP purchase the user must interact with that preference. For digital, simply displaying “1-Click” on the button infers the preference use though not displayed and for retail additional controls are given to select between other preferences, to add a gift option, and potentially other features. For CNPs this is invisible.
3. Management. All preferences have a page to change settings, either custom like Prime or shared like 1-Click.
4. Deletion. Currently preference deletion happens only as a side effect of another action, by either cancelling an order or deleting an address or instrument. Preferences would need to have a unique entity like a preference ID in order to be deleted directly.

The Only Existing Shared Preference is 1-Click

The only shared preference is the 1-Click preference service. This service is very old. It functions by associating a single credit card ID with a single address ID in a user’s address book. The user can then set an address as default and make purchases by association.
 

• There is no unique preference key. System functions on address ID.
• There is no preference or 1-Click page. Manage links point to address book.
• Deleting or editing an address erases the user’s preference because the address is assigned a new ID.
• When adding a new address, the user must manually create a new preference.
• An address is required to create a preference. Digital businesses must request an unneeded physical address.
• Since it is the only shared preference, many businesses use it in unrelated ways to the 1-Click product or behavior. For example, Retail Checkout uses it to store and populate cart defaults.
• Associations between preferences and preference use are opaque. Changing a user’s Kindle device settings will alter your defaults on Retail Checkout.
• Only one instrument ID is allowed preventing multitender preferences. For example, gift card is either always or never consumed depending on the business without consistency or transparency.
• Different businesses have different payment eligibility. This requires customers to overwrite their preference for one business conflict which then breaks other business workflows in a cyclic pattern.
• Only one purchase context for the entire site. There is no accommodation for shared accounts, work vs personal shopping, shipping to different addresses like gifting, etc.
• No summary display is included with 1-Click buttons. There is no way to confirm what is being charged or where the item is being shipped to. Creates very low confidence over lifetime.
• 1-Click adoption increases purchasing but is less used the longer the customer uses the site. Most likely as their purchase context becomes more complex and more payment methods and addresses are added over time.

The Single Sitewide Default Problem

The existing model presumes a single site-wide default payment method and single default shipping address for the entire site. When errors occur, they are suppressed. Preference behavior/usage and eligibility are opaque. A single default payment method and address can accommodate many casual US shoppers, however, highly engaged shoppers with higher average spend, international markets that primarily do not use credit cards, and new domestic digital payment methods, all suffer from such a limited model. A more flexible and extensible solution is required.

 
Problems to solve for:
 

1. No single payment method can be used for every client. This becomes pronounced internationally.
2. Engaged users often have more complex usage patterns than a single instrument or address. This directly correlates with user engagement, individual spend, and higher lifetime value of users, and will limit interaction and potential growth.
3. Some payment methods are by design limited in scope. For example COD or app-based payment methods that only work on a particular device. Industry trends show an explosion of alternative payment methods which are excluded from global preference concepts.
4. There is no current default authority. Outside of 1-Click, default notions are handled client-by-client and no mechanism exists to consolidate/orchestrate them.

Discovering Existing Customer Problems

 
I investigated existing customer problems in a few ways:
 

• I requested from the customer service department any customer complaints containing the keyword “1-Click”, “preferences”, or “settings”.
• For each relevant complaint, I extracted core problems and context along with date.
• I created metrics to demonstrate target problems: what they were trying to do, volume of complaints, and how long they had been occurring.
• Composed a general survey about 1-Click and other preferences distributed through a marketing agency to 1-Click users for secondary qualifying data.
• Created a second survey around how users would break up preferences if multiple preferences were allowed.
• Compiled quantitative data on 1-Click daily usage, number of payment methods in wallet, purchase amount/frequency, and age of account per 1-Click user to approximate lifecycle view.

Recurring problems discovered:
 

• Cyclical eligibility conflict behavior (repeatedly overwriting 1-Click for differing client eligibility).
• Confusion on where and how to manage preferences.
• Confusion on where and how preferences were used.
• Confusion about businesses that label 1-Click preferences as unique business preferences.
• Confusion resulting from suppression of errors.
• Lack of confidence on what payment method would be charged or where something would be shipped.
• Users often create duplicate addresses to hack the current system.
• Use of 1-Click increases the overall spend of a shopper. (Increases impulse purchases.)
• As users spend more time on the site, spend more money, add more payment methods, or increase their number purchase contexts, the less likely they were to use 1-Click.
• Households with multiple Kindle devices must share a single payment method for all devices.

Tenets

Building core tenets eases difficult decisions later on and unifies the product vision during design. Once established, disagreements can be externalized by matching issues with the corresponding tenet for clarity.
 

1. Simple. Always strive for the minimum amount of preferences possible.
2. Growth. Allow for organic growth in the complexity of our user’s lives and behavior.
3. Extensible. Be adaptable to new payment methods with variable scope and new regions with unexpected behaviors.
4. Transparent. Users should be clear and confident of the outcome of any purchase.
5. Don’t make me think. The task of understanding eligibility and creating/maintaining preferences should be natural and without thought and never distract from the user’s primary goal: to shop and make purchases.
6. Internally flexible. Our solution should accommodate different business and purchase models and allow for experience variation while maintaining a conceptually consistent object model for the customer. (i.e. it might look and behave a little different from client to client but as a user I still understand that this is the same preference and understand how to use and interact with it.)

Proposed Solution – Contextual Model

1. Create a new preference solution that will allow new customers to establish a site wide purchase preference while making their first purchase with a minimum barrier.
2. Expose that preference and its contents site wide where possible.
3. Intelligently handle eligibility conflicts, expanding this simple preference only when required.
4. Allow customers to name subsequent preferences.

This new model would strive for a single sitewide default but allow proliferation when necessary.
 

• Simple users will have the simplest preference possible while more complex users will always have the simplest possible solution to their individual needs without being restricted.
• Customers can easily access these preferences when purchasing and have easy visibility and confidence of the outcome of any purchase.
• Power users may easily expand upon these preferences in whichever ways make sense to them personally.
• One preference concept that can account for the myriad of individual needs and ever-expanding payment methods with the lowest bar of entry and the simplest way to purchase.

Initial Design, Testing, and Reformulation

 
Concept:
 
Instead of an independent default payment and address concept, user choices required for a purchase can be encapsulated in a named preference node (e.g. payment method, shipping speed, and shipping address). When a customer wishes to create a second purchase context a new node can be created and named (e.g. Gift for Mom). In the future when sending a gift to mom, the new preference can be selected from a dropdown at the time of purchase, lowering purchase friction. This same mechanism can be used to intelligently fork a preference when eligibility conflicts arise.
 
 
Test Experience Flow:
 
To test this experience I created a high fidelity prototype in which the user makes an initial purchase. This purchase creates an initial preference node which is populated throughout the shopping experience. The user then makes a second purchase and interacts with the new preference on their own. After the second purchase, questions are asked about the clarity and expectations of the new preference. The user is then asked how they would manage the preference. (User navigates to the Purchase Preference page.) I would then ask the user if they would find making a second preference useful and why (collect data on personal preference schemas). I then ask the user to create a second preference based on their response. I follow up by asking the user to make a third purchase with the new preference with questions about clarity and expectations.
 
 
Test Specifics:
 
The study was performed at an in-house testing facility. Participants were arranged by an external marketing firm. Subjects were comprised of Amazon shoppers, both 1-Click and non-1-Click users, male and female, users with single credit cards and multiple payment methods, with representation in 18-30, 30-50, and above 50 age groups. Other factors like level of online shopping experience and average monthly spend were collected but were not in the selection criteria. Study consisted of 12 users with two floaters (one before and one after lunch). I wrote the testing script but had a PM physically interact with participants while I observed. I provided follow-up questions after the initial study sequence.
 
 
In total, three studies were performed. 1) Initial experience study. 2) A second deep dive to uncover systemic problems. 3) A third study to validate solutions to problems uncovered in the second study.
 
 
 
Initial design user study:

• Treated both types of preferences (CP, CNP) equally.
• Users named a shared preference node and associated it with a variety of purchases.
• Initial design performed perfectly and users successfully conceptualized the contextual preference nodes.
• Users had no problem associating them with purchases and reusing them.

Feedback:

• My dev manager expressed some concerns with eligibility conflicts and fixup complexity long term. This was a deep concept and difficult to capture in an experience study.
• I redesigned the user study for further clarity.
• An eligibility conflict would be added in the existing study to evaluate cross-node associations.

Second user study:

• After several purchases were associated with a preference node, the user would update a payment method in the node which generated conflicts across the associated purchases.
• CNP conflicts required immediate fixups otherwise downstream purchases would fail.
• Even though creating and applying the preference nodes seemed clear, every participant became confused when confronted with partial conflicts across preference node associations.
• This was excellent feedback and uncovered a deep problem.

Alterations to design and concept:

• I separated CP and CNP preferences.
• To avoid eligibility complexity, I deferred error fixup for CP preferences to the point purchase so that the specific purchase context could be known fully and the user would be acting on only one purchase, reducing complexity.
• Intelligence would be baked into the selection UI so that ineligible preferences for that purchase would be greyed out based on the full context.
• Eligible preferences could then be seeded. If no valid options were available, a new preference would be collected in flow to purchase. Much simpler.
• CNP preferences would remain bespoke but housed in the authority.
• This reduced out of band conflicts to specific payment method replacement scenarios which could be more easily messaged in a Universal Fixup feature.
• It also allowed for subscription-specific preference data like recurrence and other business specific information to be collected.
• Housing both types of preferences in a Universal Preference Authority still allowed for a single preferences page and universal fixup for lost or new cards.

Third user study:

• A third user study was performed to validate the assumptions of the new design.
• The new design diffused complexity successfully allowing customers to handle the deep eligibility conflicts introduced in the second study.
• The Update Everywhere feature that allows for new payment methods to be populated across preferences became a central aspect of the design. This feature spawned its own studies and became a project unto itself.

General Strategy – Our Path Forward

1. Create a universal preference authority. This authority would house all purchase preferences site-wide, allow cross-client visibility, enable site-wide fixup of payment and address changes, and allow for multi-tender payment preferences. Migrate businesses to this service.
2. Universal update. When a user makes a change to a payment method or address we can now scan their existing preferences and allow them to populate that change across the set and fix conflicts.

For Shared 1-Click Preference (CP):

3. Move to a unique Preference ID instead of an address ID and make each preference element optional. In this way each business can collect only what their purchase requires. Subsequent businesses can collect additional information in flow to purchase when needed.
4. Move to a user supplied name as the primary differentiation for shared preferences. Initial preference name can be generated but subsequent names should be user driven. This allows for highly variable user schemas with minimal effort or UI. (Studies show user schemas are too various to quantify.)
5. Reword the 1-Click preference phrasing as a “Purchase preference” or similar generalized language instead of the overly specific 1-Click preference language. Divorce the preference store (preference selection) from the 1-Click method of purchase (buy with 1-Click button). This way the new preference can be used for 1-Click purchases, Buy Now purchases, and on SPC as the same preference if desired.
6. Consistent UI. Create a standard consumption UI that allows selection of alternative preferences, a display of selected preference contents, and the ability to create a new preference while purchasing. I envision this as a widget that encapsulates the complex eligibility logic.
7. Upon first purchase, create a purchase preference and populate it across all CP consumption UIs. For most users this should effectively be a single global default. End of story. We can then use this preference to seed CNP purchases, turbo checkout default options, etc. A very low bar.
8. Handle conflicts at the point of purchase. If the current preference is ineligible, instead of overwriting a single default, we can fork the single preference into a second. This new preference could then be preselected in subsequent scenarios when needed.

 
They key here is to move to a context driven selection model to determine usage intelligently.

Retail Checkout:

9. Expose preference selection on the retail summary page when more than one preference is available. For customers with only one preference, suppress the selection UI.

For Subscriptions and Other CNPs:

10. Keep CNP preferences unique. We can’t defer complexity to the point of purchase and users struggle conceptualizing eligibility fixup broadly. Moving these preferences into a shared authority still allows for instrument level fixup across the preference landscape. This also allows for unique subscription level logic and features.

Other areas:

11. Enable device level preferences. We can seed device preferences from a user’s primary preference but allowing for stand-alone device preferences will: isolate legacy devices from the shared ecosystem, allow device specific payment methods, and enable multiple devices (spouse, work, etc.) on a single Amazon account to use different payment methods.

Contextual Expansion

Building on this contextual model we can then add contextual queues to purchase preference entities. This added context would be very useful to tailoring purchase experiences within those contexts and informing charge logic and instrument selection/ordering. We already do this when adding an address with the optional field of work or home. If we expand that selection to include say Address for Gifting then we can infer that this address is less likely to use a work related card. Similarly knowing if a new payment method is Personal or For Work allows for betting wallet cycling behaviour. But this data collection would need to be tested against the barrier to entry (more form complexity).

Paradigm Shift

This approach requires a transition from the current single default to a less determinate contextual default. This shift is key to solving the single default problem. Two primary requirements arise:

1. The ability to change the preference selection. Adding a change link would be sufficient. Dropdown selection is preferred where space permits.
2. The ability to name a new preference when it’s created. This allows for simple user generated schemas which are highly variable between users and difficult to quantify.