Product Principles & Patterns

Recommendations at this scale aren't one feature - they're dozens of placements across the homepage, search, product pages, cart, and post-purchase, each owned by a different team but built from the same shared component library.

Having a mature component library didn't stop the experience from feeling inconsistent. Components give you visual consistency, not decision consistency - they don't tell you when to show a recommendation, how to explain why someone is seeing it, or how to balance what the user wants against what the business wants.

• Dozens of placements, each able to ship independently
• The same recommendation logic reused for very different user intents
• No shared answer for "why is this module here, and why this content?"

The same pain point kept surfacing in research, worded almost the same way every time: "Why am I seeing this?" When people don't understand why something is being shown to them, they stop trusting it - and no amount of component polish fixes that on its own.

Before writing a single rule, the team needed to agree on what we were actually building. "Principle," "pattern," and "component" were being used interchangeably - and that ambiguity was part of the original problem.

Mature design systems document all three layers, not just the UI layer at the bottom. Ours, like most, only had that third one written down.

Principles that one person writes alone rarely survive contact with a real team - they needed to be co-owned from day one, by the people who'd actually have to apply them under deadline pressure. That shaped the entire process, not just the final wording. Before anyone in the room saw a draft, it had to stand on something more solid than opinion:

• Promises already made to customers and sellers elsewhere in the product strategy
• Prior usability research, including a dedicated study on recommendations across the purchase path
• Third-party UX benchmarks for the category
• Customer experience index data and competitive analysis
• Learnings pulled from recent high-stakes launches

The draft then went into the room with four explicit goals - not just "give feedback":

• Align everyone on how things actually worked today, before debating how they should work
• Align on where the short- and medium-term strategy was heading, so principles wouldn't be obsolete in a quarter
• Walk through the research and the first draft together, in the open, so no one was defending it alone
• Leave with a v0.1 the room had actually argued into shape, not one person's opinion with a stamp of approval

AI helped here too - not to write the principles, but as a sparring partner: synthesizing research notes, clustering recurring user complaints, and poking holes in early drafts before they reached the room. It sped up the synthesis. The workshops, and the disagreements inside them, are still what made the principles stick.

What the team agreed on, in four rules rather than forty:

Principles only earn their keep once they can resolve a real disagreement. A few examples from the rollout:

When one placement had to serve three goals at once - sponsored content, shipping consolidation, and alternatives - the pattern didn't tell the business "no." It said "how": segment by user goal with contextual tabs, each one mapped to a single, distinct purpose.

Some patterns exist because the law requires them, not because research suggested them. Price and promotion transparency - always showing the recent reference price next to a discount - gave the team solid ground to say "this one isn't negotiable" when it mattered.

I tried not to design these principles in a vacuum. The same underlying value shows up in other AI-driven parts of the product, even though the pattern that implements it looks completely different.

Same value, two different products, two different patterns. Looking for that overlap kept the principles from becoming yet another siloed artifact.

Before this version worked, an earlier attempt at the same idea didn't. A few reasons principles and patterns quietly stop being used:

• They live apart from the tools people actually work in, as a document nobody opens
• They're too general to resolve an actual disagreement
• They're too rigid, blocking valid business needs instead of showing a path through them
• They have no clear owner, so they quietly stop being updated after a quarter

Keeping them alive meant putting them where daily work already happens, rather than one more place to remember to check. The finished set now lives directly inside the design system alongside the components that implement it.

AI now has a second role here too: helping draft new patterns consistent with the agreed principles as the recommendations surface keeps growing. AI proposes, a designer still validates every one before it ships - the principles are there to serve the product, not the other way around.