Purchase Preferences & Defaults

The system I found

No unified preference authority existed. Businesses collected, stored, consumed, and managed their preferences internally, with one exception: the shared 1-Click preference. Because each business wholly owned its own preference storage, it was impossible to view a customer's preferences in one place. When something went wrong (an expired card, a new home address), the customer had to discover on their own which preferences existed across Amazon, locate each management page, and update them by hand. Preferences were routinely overlooked, causing purchase failures across the site, customer headache, and millions in lost revenue.

The shared 1-Click service itself was very old, and its mechanics explain most of the damage. It worked by associating a single credit card ID with a single address ID, no unique preference key, no preference page of its own, and deleting or editing an address silently erased the preference because the address got a new ID. Digital businesses had to request a physical address they didn't need. Because it was the only shared preference, businesses used it for unrelated purposes; Retail checkout used it to store cart defaults, so changing your Kindle device settings could silently alter your Retail checkout defaults. One instrument ID meant no multi-tender preferences; gift cards were either always or never consumed depending on the business. There was no summary on 1-Click buttons, no way to confirm what would be charged or where an item would ship.

Underneath all of it sat one structural assumption, a single sitewide default payment method and address. That model can serve a casual US shopper. It fails precisely for the customers who matter most, though, highly engaged shoppers with complex purchase contexts, international markets that don't run on credit cards, and the exploding landscape of scoped payment methods that only work on one device or in one context. The data agreed, 1-Click usage declined the longer a customer used Amazon, as their accounts accumulated payment methods, addresses, and contexts the model couldn't represent.

Mapping it

Discovery ran on three dimensions: how preferences and their lifecycles actually worked, what problems customers were actually having, and what the businesses consuming preferences actually required.

The preference audit

The only way to understand preferences broadly was to audit the site, business by business. Two types emerged with similar lifecycles but very different requirements. Customer Present (CP) preferences are convenience shortcuts (1-Click and cart defaults) used while the customer is there to react to whatever comes up. Customer Not Present (CNP) preferences charge future orders (Prime, Subscribe & Save, periodicals), where errors must be handled out of band and language must be future-looking, because the customer isn't in the room when the charge happens.

The lifecycle has four contexts: creation (usually a silent artifact of a purchase), consumption, management, and deletion. The last one was telling. Preferences could only be deleted as a side effect of deleting something else. They didn't even have their own identity.

Finding the customer problems

I pulled every customer-service complaint containing "1-Click," "preferences," or "settings," extracted the core problem and context from each, and built metrics (what customers were trying to do, complaint volume, and how long each problem had persisted). I ran a general survey of 1-Click users through a marketing agency, then a second survey on how users would split their preferences if they were allowed more than one. I compiled quantitative data on daily 1-Click usage against wallet size, purchase frequency, and account age to approximate a lifecycle view.

The recurring problems: cyclical eligibility conflicts (users repeatedly overwriting their one default to satisfy different businesses, breaking other workflows each time); confusion about where preferences were managed and where they were used; errors suppressed into silence; no confidence about what would be charged or shipped where; users creating duplicate addresses to hack the system; and households sharing one payment method across every Kindle device because the model allowed nothing else. Also confirmed, 1-Click increases overall spend, and its use falls off exactly as customers become more valuable.

The design

Six tenets governed the work: simple: always the minimum number of preferences possible; growth: organic expansion as users' lives get more complex; extensible: adaptable to new payment methods and regions; transparent: users should be confident of the outcome of any purchase; don't make me think: eligibility and maintenance should never distract from shopping; and internally flexible: one conceptually consistent object model for the customer, even when its presentation varies by business.

I proposed a new model. A customer's purchase choices (payment method, address, shipping speed) are encapsulated in a named preference node, created with minimal friction during the first purchase and exposed sitewide. For most customers, that's the whole story, one preference, everywhere. When a real second context appears ("Gift for Mom"), the customer names a new node, and it's available from a dropdown at purchase time. Eligibility conflicts fork a preference intelligently instead of overwriting the only one. Simple users get the simplest possible experience; complex users get the simplest solution to their complexity.

Three studies and a pivot

I tested the concept with a high-fidelity prototype. The participant makes a purchase (creating their first preference node), makes a second purchase interacting with the preference unprompted, navigates to manage it, designs their own second preference, and purchases with it, with structured questions about clarity and expectations at each stage. Studies ran at an in-house facility with participants recruited by an external firm, twelve users plus two floaters per study, balanced across 1-Click and non-1-Click shoppers, single-card and multi-card wallets, and three age bands. I wrote the scripts; a PM ran the sessions while I observed.

Study one: the initial design, which treated CP and CNP preferences identically, performed cleanly. Users conceptualized the nodes, associated purchases with them, and reused them without trouble.

Study two: my dev manager raised a concern the first study couldn't see, long-term eligibility conflict and fixup complexity. I redesigned the study to force it. After several purchases were associated with a node, participants changed a payment method inside it, generating conflicts across the associated purchases. Every participant got lost in the partial conflicts. Creating preferences was clear; repairing them across contexts was not. That failure was the most valuable data in the project.

The pivot: I separated CP and CNP preferences. CP error fixup was deferred to the point of purchase, where the full context is known and the user is dealing with exactly one purchase. Eligibility intelligence moved into the selection UI. Ineligible preferences grey out, eligible ones seed the flow, and if nothing valid exists a new preference is collected in the purchase flow itself. CNP preferences stayed bespoke, with room for subscription-specific data like recurrence, but moved into the shared authority, so instrument-level fixup still works across the whole landscape through a single Update Everywhere feature.

Study three validated the pivot. The new design diffused the complexity, and participants handled the same deep conflicts that had defeated study two. Update Everywhere, which populates a new payment method across all preferences from one modal, became a central feature and then a project of its own.

Adoption

The design resolved into an eleven-point path forward, anchored by two structural moves: a Universal Preference Authority housing every purchase preference sitewide (cross-client visibility, sitewide fixup, multi-tender support) and Update Everywhere, which scans a customer's preferences when a payment method or address changes and populates the fix across the set. Around those, unique preference IDs to replace address-ID coupling, user-supplied names as the primary differentiator (studies showed personal schemas are too varied to quantify), generalized "purchase preference" language divorced from the 1-Click purchase mechanism, a consistent consumption widget encapsulating eligibility logic, conflict handling at the point of purchase, and device-level preferences so a household's Kindles no longer share one forced payment method.

I launched the Universal Preference Authority and Update Everywhere. Key off-team dependencies were still in development when I left Amazon, so the full contextual vision hadn't shipped end to end at my departure. On a system this deep, the concept model, the validated design, and the authority it runs on are the durable contribution.

Outcomes

• 2 launchedUniversal Preference Authority and Update Everywhere shipped as the structural foundation of the new model
• 3 studiesformal user studies (12 participants + 2 floaters each), including one designed to break the concept, which did, productively
• 1 pivotCP/CNP separation with point-of-purchase fixup, the design change that made deep eligibility conflicts survivable
• 9 flawsdocumented structural failures of the legacy 1-Click model, each traced to a mechanism, not a symptom

What I'd tell you about it now