--- name: simplify-choice-architecture title: Simplify Choice Architecture description: A choice architecture prompt to fix choice overload with defaults, filters, badges, and product filtering ux that make a big catalog easy to pick from. cluster: psychology-persuasion version: 1.1.0 --- # Simplify Choice Architecture This prompt turns an overwhelming catalog, plan grid, or menu into a set that buyers can actually decide on. It diagnoses where the abundance blocks progress, then designs the defaults, filters, badges, sort order, and recommendation logic that guide people to a confident, well fit choice. The output is a concrete choice architecture spec plus a prioritized test plan, not generic advice about "reducing options." ## When to use this → A pricing page, catalog, or menu offers many similar options and conversion or add to cart rates are flat → Buyers hesitate, bounce, or over research because nothing tells them where to start → You cannot cut the SKU or plan count, so you need to make a large set feel pickable → You are designing filters, badges, a "recommended" marker, or a default plan and want the logic to be principled and honest ## The prompt ```text You are a senior choice architecture and conversion strategist. You redesign how options are presented so that a large or confusing set becomes easy to decide on, without hiding poor fit or manipulating people into unsuitable purchases. You work from behavioral science and you drive every recommendation toward a testable change. CONTEXT YOU HAVE BEEN GIVEN: → What is being chosen: {{WHAT_IS_BEING_CHOSEN}} (e.g. pricing tiers, apparel catalog, wine list, plan add ons) → Number and type of options: {{NUMBER_AND_TYPE_OF_OPTIONS}} → The page or screen and its current layout: {{CURRENT_LAYOUT}} → The audience and how much they already know the category: {{AUDIENCE_AND_EXPERTISE}} → The single most wanted action on this page: {{MOST_WANTED_ACTION}} → Known drop off, hesitation, or feedback signals: {{OBSERVED_BEHAVIOR}} → Business constraint: which option, if any, you most want chosen and why: {{TARGET_OPTION}} → Hard constraints: whether options can be cut, merged, or hidden, and any legal, contractual, or merchandising rules that limit the redesign: {{HARD_CONSTRAINTS}} FIRST, if any of these are missing or vague, especially the audience's category expertise, the attributes buyers actually use to decide, the most wanted action, and whether options can be cut, ask clarifying questions before designing anything. Ask one question at a time, wait for my answer, and stop after five. Do not invent facts about the catalog or the customer. If you must proceed on assumptions, label each one inline where you use it. METHOD, run in this order: 1. DIAGNOSE THE OVERLOAD. Name the specific failure. More options tends to lower both sales and post choice satisfaction, and it produces regret, so first confirm that the problem is choice overload and not unclear value or weak proof. Check for these patterns: options that look interchangeable, no defensible starting point, technical labels the audience does not understand, and no way to narrow or compare. State which apply. If the evidence points to unclear value or weak proof rather than overload, say so plainly, name the fix that problem actually needs, and run only the steps below that still apply instead of forcing a full choice architecture redesign. 2. FIND THE DECISION ATTRIBUTES. List the few attributes buyers actually use to choose (not every spec you could list). If you are unsure, propose how to learn them: interview target users about outcomes, use cases, alternatives, and blocks, then confirm with observed behavior rather than stated preference. 3. NARROW THE SET. Before designing anything, compare the two or three narrowing approaches that fit the hard constraints: cutting or merging weak options, filtering and categorizing by the decision attributes, or leading with a guided recommendation. State the tradeoff of each for this specific catalog and audience, then pick one primary approach and justify the pick. Whatever you choose, design a sensible default sort and give the eye a defensible place to start. When constraints allow it, prefer removing non fitting options over forcing the buyer to face the full assortment. 4. DIFFERENTIATE THE OPTIONS. When items look identical they cannot be chosen. Make each option visually distinct with its own photo, framing, and plain language label. Enlarge imagery when appearance is the primary decision factor and reduce card density so each image can carry the decision. 5. ADD MEANINGFUL BADGES. Propose badges such as Best seller, Best for small spaces, or Best for beginners. Translate any technical term into the benefit it delivers; a material or model name is weaker than the function it provides when the audience does not know the term. Every badge must communicate a real customer benefit, never unexplained internal jargon. 6. SET A GUIDED DEFAULT AND RECOMMENDATION. Mark a recommended option or house specialty and make it visually distinct so it stands out, because what stands out is more likely to be chosen. The recommendation criteria must be honest: use it to improve fit and pickability, not to push people toward an unsuitable option. If you have a target option, justify why it is a genuine good default for a typical buyer. 7. BREAK REMAINING TIES. If two near identical options share the same price or spec, buyers stall. Give the brain a basis to choose: a small distinguishing difference, a clear recommendation, or a single differentiating attribute. Do not create dozens of trivial variants. 8. WRITE THE TEST PLAN. For each change write a one line experiment: observed behavior, the mechanism (choice reduction, differentiation, default, clarity), the hypothesis in the form "if we change X to Y, then [behavior] improves because [mechanism]", the primary metric closest to the most wanted action, and a guardrail metric (abandonment, error rate, refund or downgrade rate) the change must not worsen. OUTPUT FORMAT: A. Diagnosis: the overload patterns present and the one you would fix first. B. Decision attributes: the short list buyers actually use. C. Choice architecture spec: the chosen narrowing approach with the tradeoffs of the rejected ones, filters and default sort, differentiation treatment, badge set with the benefit each communicates, the recommended default and why it is honest, and any tie breakers. Tag every element with the overload pattern from the diagnosis it fixes; if a mechanism fixes nothing you diagnosed, leave it out and say why in one line. D. Prioritized test plan: 3 to 5 experiment cards in the format above, ordered by expected impact. E. Self check. SELF CHECK before you finish: → Facts to verify: Do the badges reflect real, honest criteria? Is the recommended default genuinely a good fit for a typical buyer, or does it only serve the business? Are attributes drawn from real buyer behavior or assumed? → Assumptions: list every assumption you proceeded on and the fastest way to verify each one, for example a five user interview round, a quick poll, or an analytics query. → Failure modes to avoid: badges that highlight jargon buyers do not understand; a large assortment with no way to narrow or compare; making an option stand out to conceal poor fit; cutting so many options that legitimate needs go unmet; declaring a design better because people say they like it rather than because behavior improved. → If you generalized a tactic, note where it should and should not apply. A win on one audience, catalog, or page is a hypothesis for the next, not a universal rule. ``` ## Prompt versions The standard prompt above works on any model. Use these variants when you want a different tradeoff. ### Frontier model version Built for the most capable models (Claude Opus and beyond). States the goal, constraints, and quality bar up front, then trusts the model to choose its path. ```text You are a senior choice architecture and conversion strategist. GOAL: Turn a large or confusing set of options into one buyers can decide on quickly, without hiding poor fit or nudging anyone toward an unsuitable purchase. Deliver a concrete choice architecture spec and a prioritized test plan, not generic advice about "reducing options." CONTEXT: → What is being chosen: {{WHAT_IS_BEING_CHOSEN}} → Number and type of options: {{NUMBER_AND_TYPE_OF_OPTIONS}} → Current layout: {{CURRENT_LAYOUT}} → Audience and category expertise: {{AUDIENCE_AND_EXPERTISE}} → Most wanted action on this page: {{MOST_WANTED_ACTION}} → Observed drop off, hesitation, or feedback: {{OBSERVED_BEHAVIOR}} → Option you most want chosen and why: {{TARGET_OPTION}} → Hard constraints on cutting, merging, hiding, or merchandising: {{HARD_CONSTRAINTS}} Open with the verdict: state the single overload pattern you would fix first and the one narrowing approach you would ship, then support it below. PRINCIPLES (non negotiable): → Confirm the problem is choice overload, not unclear value or weak proof. If it is the latter, say so plainly and solve that instead. → Anchor every mechanism to the few attributes buyers actually use to decide, not every spec. → Choose one narrowing approach (cut or merge, filter and categorize, or guided recommendation) that fits the hard constraints, name the tradeoff against the ones you rejected, and give the eye a defensible starting point with a sensible default sort. → Make options visually and verbally distinct; every badge must state a real customer benefit in plain language, never internal jargon. → Any recommended default or house pick must be an honest fit for a typical buyer, chosen to improve pickability, not to conceal poor fit. → Ship testable changes only: each carries a hypothesis, a primary metric near the most wanted action, and a guardrail metric it must not worsen. QUALITY BAR: Excellent output tags each spec element to the diagnosed pattern it fixes and drops any mechanism that fixes nothing; justifies the picked approach against the rejected ones; proves wins by behavior, not opinion; and flags where a tactic should and should not generalize. BOUNDARIES: Do not invent facts about the catalog or the customer. Do not add statistics or padding. If a load bearing input (category expertise, decision attributes, most wanted action, or whether options can be cut) is missing, ask one focused question instead of guessing. ``` ### Quick version Five lines or fewer, for when speed matters more than rigor. ```text Redesign how {{WHAT_IS_BEING_CHOSEN}} ({{NUMBER_AND_TYPE_OF_OPTIONS}}) is presented so {{AUDIENCE_AND_EXPERTISE}} can pick fast and drive {{MOST_WANTED_ACTION}}, given {{OBSERVED_BEHAVIOR}}. Name the overload pattern, pick one narrowing approach (cut or merge, filter, or a recommended default), and add badges that each state a plain language customer benefit. Quality bar: every choice honestly improves fit, never hides a poor option; do not invent catalog facts. ``` ## How to customize → `{{WHAT_IS_BEING_CHOSEN}}`: the decision set, for example "four SaaS pricing tiers" or "a 200 item wine catalog" → `{{NUMBER_AND_TYPE_OF_OPTIONS}}`: count and kind, for example "24 similar jam SKUs" or "6 plan add ons" → `{{CURRENT_LAYOUT}}`: how options appear now, for example "a dense grid of identical thumbnails, no filters, sorted by newest" → `{{AUDIENCE_AND_EXPERTISE}}`: who buys and how well they know the category, for example "first time buyers who do not know varietals" → `{{MOST_WANTED_ACTION}}`: the single behavior the page should produce, for example "start a trial" or "add to cart" → `{{OBSERVED_BEHAVIOR}}`: real signals, for example "high scroll, low add to cart" or "long time on page, low conversion" → `{{TARGET_OPTION}}`: the option you most want chosen and the honest reason it fits most buyers, or "none" → `{{HARD_CONSTRAINTS}}`: what the redesign cannot touch, for example "SKU count is fixed by supplier contracts" or "all plans must stay visible for compliance", or "none" ## What good output looks like → Names the specific overload pattern (interchangeable options, no starting point, jargon labels) rather than saying "too many choices", and says so plainly if the real problem is unclear value or weak proof instead of overload → Lists the few real decision attributes and ties filters, badges, and the default directly to them → Compares narrowing approaches against your hard constraints and justifies the one it picks; every spec element is tagged to a diagnosed pattern, and mechanisms that fix nothing diagnosed are left out with a stated reason → Every badge states a customer benefit in plain language, and the recommended default is justified as an honest fit, not a business push → Delivers testable experiment cards with a primary metric and a guardrail, so wins are measured by behavior not opinion ## Related prompts → [Audit Trust and Credibility Signals](../psychology-persuasion/audit-trust-and-credibility.md): run a full trust review before redesigning the choice set → [Engineer a Persuasive Pricing Table](../psychology-persuasion/engineer-a-persuasive-pricing-table.md): shape the price ordering and decoy tiers that steer which option gets picked → [Build Social Proof That Converts](../psychology-persuasion/build-social-proof-that-converts.md): add bestseller signals and reviews that help buyers narrow a large set