Overview  

Reconceptionalizing the single purchase default into a universal preference service

• Analysis of the existing purchase preference landscape.
• A single payment default is not sufficient for active users.
• Current eligibility conflicts are hidden and create confusing/cyclical behavior.
• One-click adoption is low primarily due to low confidence at purchase action.
• Initial purchase preference should be captured at first purchase with a naming concept.
• When eligibility conflicts occur during purchase or at the request of the user, additional preferences should be allowed.
• Individual conceptualizations of preference structure is highly variable. Proliferation concepts should be user controlled. (e.g. Work vs home, package for mom, large vs small package delivery)

Supplemental Documents  

Amazon Purchase Preferences Analysis and Solution (Word document)

Amazon Purchase Preferences Design (PowerPoint)

In Detail  

    There is no universal preference service at Amazon. Each business hosts and maintains their own client preferences. The one exception is the 1-Click preference which associates a single credit card ID with a unique address ID. The construction of this preference is not apparent and is very limited.

     Sometimes purchases using this preference are clearly identified like 1-Click purchasing on retail details pages. But the contents of the preference are not displayed. So you’re never sure which card is being charged or where the item is being shipped to. Throughout a user’s lifecycle, shipping addresses and payment methods change, so confidence is very low when using the feature.

     Other times, clients attach themselves to the 1-Click preference but message the preference as their own preference or not at all, for example Prime Video. Still other clients like Kindle use client specific language on stand-alone settings pages like Kindle Purchase Preference when in fact they’re displaying the 1-Click preference.

     Still others use the 1-Click preference in scenarios which are not 1-Click like for subscriptions and hence don’t use the messaging.

     The main problem with a single default lies in eligibility. Eligibility of a payment method is derived from a complex backend service that analyzes the product or collection of products, the payment method set, the shipping address, the region, and a host of business and contractual rules that return a binary response and poor error codes. When a purchase using the single default fails, it could be for any number of reasons, usually not the validity of the payment method. A common example would be attempting to purchase a digital product using Cash on Delivery (COD).

     Currently when the single default fails in a pipeline for any reason, a fixup experience is presented and overwrites the single default. This usually in turn breaks all of the other client purchase experiences, which will later trigger their own fixup and overwrite the single default again in a perpetual loop. None of this is exposed on the surface and is frustrating and opaque to the user.

     Likewise, since the preference is based on an address ID, interaction with an address can alter your payment default unexpectedly. If an address is edited for example, it is assigned a new address ID to avoid complicating orders already undergoing fulfillment. The new address, though potentially identical in the UI, loses all of its associations to the preference.

     And finally, since the preference concept touches such a broad set of clients, explaining the existing defects and finding agreement on a new solution is very challenging. 

     The solution is to first create a universal preference service and transition defaults to a preference ID, not the address ID. The single default can then be divorced from unexpected address behaviors. A purchase preference page is created in the account section to view and edit the purchase preference.

     Second, a naming concept should be added to allow the user to create whatever concepts that suit their purchase behavior. Naming creates an implicit proliferation/customization. This is a common pattern, for example creating and initial Wish List with the ability to create additional named lists with their own settings. During the user’s initial purchase, seed a name (but allow editing), and create the initial single default. This default can then be propagated and exposed wherever it is usable. Divorce the 1-Click name from the preference which becomes the “purchase preference” and associate 1-Click messaging with the purchase action (button), not the preference. This associates the specific preference to the global purchase preference concept and allows a much broader use for non-1-Click scenarios.

     Create a minimal display of the preference contents associated with any button that acts on it (like a digital purchase button). This solves almost entirely the trust problems associated with 1-Click. The display then acts as a control to switch between existing preferences.

     When eligibility conflicts occur at the point of purchase, the user encounters a fixup flow. Allow the user to save the new choices as a preference seeded with an editable contextual name based on the eligibility conflict (e.g. “Digital purchases”). When the user encounters a similar problem on a different digital client page, both preferences can be evaluated when the details page is loaded and the eligible preference can be seeded in the selection display. This type of soft default and eligibility seeding minimizes preference proliferation while solving the overwriting loop error.

     New preference groups can be created by advanced users on the purchase preference page to accommodate advanced purchasing behavior. The limitations of use of 1-Click for advanced users usually revolves around its single default nature and lack of visibility.