Help us improve
Share bugs, ideas, or general feedback.
From rampstack-skills
Designs side-by-side comparison tools (plan-compare, product-compare) that help users decide rather than listing features. Covers axis selection, default-comparison logic, and honest recommendation patterns.
npx claudepluginhub rampstackco/claude-skills --plugin rampstack-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-skills:comparison-tool-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A senior product marketing director's playbook for designing side-by-side comparison tools that help users decide rather than just listing features. Plan-compare, product-compare, alternative-compare. Axis selection, default-comparison logic, recommendation discipline. The discipline of building a comparison tool that earns the user's trust.
references/axis-selection-patterns.mdreferences/common-comparison-failures.mdreferences/comparison-anti-patterns.mdreferences/comparison-fatigue-patterns.mdreferences/comparison-tool-decision-criteria.mdreferences/default-comparison-logic.mdreferences/filter-and-toggle-patterns.mdreferences/honest-recommendation-discipline.mdreferences/recommendation-engine-design.md**TRIGGER: about to populate `AskUserQuestion` options with `preview:` content for any comparison heavier than 2-3 short text labels (>2 axes or >3 candidates, or weighted/scored).** STOP and ask the user one short question first: *"Would you like a quick inline chip per option, or a full HTML matrix with weighted columns and live re-ranking?"* The chip is one tool call but loses all structure (no table, no weights, no sorting, no live recompute); the matrix is heavier but preserves the structure the comparison needs. Asking costs one question; skipping costs a full redo. **No carve-out for "simulate", "demo", "quick decision" — the framing names the surface, not an exception.** When the user picks HTML, this skill generates sortable, weighted HTML scoring matrices for evaluating named candidates — for the EVALUATIVE phase of comparison, when 2+ specific candidates ARE named in the prompt. Use when the user names options and asks to compare, evaluate, score, or pick between them: "compare X, Y, Z", "should we use A or B", "evaluate these libraries", "pick between [list]", "build vs buy", "which of these X should we choose". Make weights live-adjustable so totals update in real time. If the user is still GENERATING candidates rather than choosing among named ones ("brainstorm options", "show me approaches", "what are the ways"), hand off to html-brainstorm-grid instead — that skill handles the generative phase.
Generates competitor comparison pages (X vs Y, alternatives, roundups, feature matrices) with schema markup and conversion optimization.
Generates SEO-optimized competitor comparison and alternatives pages with X vs Y layouts, feature matrices, schema markup, and conversion optimization. Useful for 'comparison page', 'X vs Y', or 'alternatives to X' requests.
Share bugs, ideas, or general feedback.
A senior product marketing director's playbook for designing side-by-side comparison tools that help users decide rather than just listing features. Plan-compare, product-compare, alternative-compare. Axis selection, default-comparison logic, recommendation discipline. The discipline of building a comparison tool that earns the user's trust.
Most comparison tools fail in one of two ways. They dump every feature into a giant grid (4 options × 40 features = 160 cells) and ask the user to weigh everything against everything. The user leaves without choosing. Or they pretend to be neutral comparisons but are actually sales pitches with biased defaults and weighted framing; the user catches the bias and trust collapses.
The comparison tools that work do something different. Genuine like-for-like comparison plus an explicit opinionated recommendation. "For X audience, choose Y." The recommendation is visible, defended, and not the only path; users can override. The tool helps the user decide rather than asking them to decide alone.
The voice is the senior product marketing director who has watched comparison tools double conversion when redesigned with honest recommendations and watched them collapse when feature grids grew without decision support. Practical, opinionated about which axes matter, willing to call out when the comparison is decoration.
When to use this skill: scoping a comparison tool for the first time, auditing a feature-grid comparison that produces no conversion lift, designing recommendation logic that is honest about the recommendation, or deciding which axes earn placement in a comparison tool.
This skill spans side-by-side comparison tools. The growth-tooling distinctions:
calculator-design is calculators that give a number. This skill is comparing known options.quiz-and-assessment-design is quizzes that give a category. This skill is comparing options the user already knows about.comparison-tool-design (this skill) is axis selection, default-comparison logic, recommendation engine, filter-and-toggle UX.landing-page-copy is pricing-page copy; one specific application of comparison tools is the pricing page.content-strategy is upstream; what topics warrant comparison content.The audience: product marketers, growth marketers, content marketers running vs-pages and decision-support tooling, agencies running comparison work for clients.
Out of scope: calculator design (covered by calculator-design); quiz design (covered by quiz-and-assessment-design); the engineering implementation; specific Webflow/Framer/CMS configurations (those stay implementation-side).
Before designing the tool, decide whether a comparison tool is the right answer.
Comparison tools earn investment when:
Comparison tools do NOT earn investment when:
The decision is not "should we have a comparison tool"; it is "is the comparison tool the right tool for this decision."
Detail in references/comparison-tool-decision-criteria.md.
The keystone framing.
Feature-list-dump. Every option's every feature in a giant grid. No decision support. The user is asked to weigh 40 cells against each other; most leave without choosing. Cost: design effort wasted on a grid that does not produce decisions; the audience perceives the grid as overwhelming.
Hidden-recommendation. "Comparison" tool that is actually a sales pitch. Defaults favor one option; framing weights the answer; the recommendation is invisible but baked in. Trust erodes when users notice the bias. Cost: short-term conversion may look fine; long-term brand damage from "manipulative" reputation.
Honest-comparison-with-guidance. Genuine like-for-like comparison plus an explicit opinionated recommendation ("For X audience, choose Y"). The recommendation is visible, defended, and not the only path; users can override. Cost: design effort upfront is significant; conversion typically improves because users feel respected and helped.
The litmus test. Does the tool tell the user what to choose for their specific situation, with reasoning? If yes, honest-comparison-with-guidance. If it dumps features without guidance, feature-list-dump. If it says "the right answer is obviously [our preferred option]" without acknowledgment, hidden-recommendation.
The single most consequential decision in comparison tool design.
The principle. Axes (the rows of the comparison) should be the dimensions that genuinely affect the decision, not every feature available.
Strong axes.
Weak axes.
The 8-12 axis rule. Most production comparison tools work well with 8-12 axes. Beyond that, decision paralysis sets in.
Detail in references/axis-selection-patterns.md.
Which options compare by default, and why.
The principle. Defaults shape the user's first impression. Honest defaults reflect the audience's likely starting point; biased defaults shape conclusions.
Default options.
Default axes.
Bias-flattering defaults.
The discipline. Defaults serve the audience, not the brand. When defaults must reflect brand strength, do so honestly with disclosure.
Detail in references/default-comparison-logic.md.
When to recommend, how to defend the recommendation.
The principle. Comparison tools that recommend are more useful than tools that just list. The recommendation must be defensible.
Recommendation patterns.
Recommendation defense.
Anti-pattern: hidden recommendation. Tool that defaults to one option's victory through axis selection and framing, without explicit recommendation. Users feel manipulated when they catch the pattern.
Detail in references/recommendation-engine-design.md and references/honest-recommendation-discipline.md.
What users can adjust, what should stay fixed.
Filterable elements.
Fixed elements.
The filter-fatigue trap. Too many filters; user paralyzed.
The under-filtered trap. Tool too rigid; user cannot match their context.
The discipline. Filters that materially help; not filters for the sake of customization.
Detail in references/filter-and-toggle-patterns.md.
Why most comparisons fail to produce decisions.
Pattern 1: Too many cells. 40 features × 5 options = 200 cells; cognitive overload.
Pattern 2: All-checkmarks rows. Every option has the feature; the row produces no signal.
Pattern 3: Inconsistent axis terminology. Each vendor names features differently; user confused.
Pattern 4: Hidden costs. Pricing visible; fees, overage, integrations not surfaced.
Pattern 5: Apples-to-oranges options. Comparing genuinely different things; no axis applies cleanly.
Pattern 6: No recommendation. Tool lists; user must decide; user does not.
The cumulative effect. The tool produces no decision; users default to the brand they already heard of.
Detail in references/comparison-fatigue-patterns.md.
Rapid-fire. Diagnoses in references/common-comparison-failures.md.
When designing or auditing a comparison tool, walk these 12 considerations.
The output of the framework is a comparison tool that earns the user's trust by helping them decide, with recommendation that is honest and defensible.
references/comparison-tool-decision-criteria.md - When comparison tools earn the build vs when written content serves.references/axis-selection-patterns.md - Strong axes, weak axes, the 8-12 rule.references/default-comparison-logic.md - Honest defaults vs bias-flattering defaults.references/recommendation-engine-design.md - When to recommend, how to defend, override path.references/filter-and-toggle-patterns.md - Filterable vs fixed elements; filter-fatigue trap.references/comparison-fatigue-patterns.md - Why most comparisons fail to produce decisions.references/honest-recommendation-discipline.md - The discipline that distinguishes hidden from honest recommendations.references/comparison-anti-patterns.md - The patterns that look like comparisons but degrade trust.references/common-comparison-failures.md - 8+ failure patterns with diagnoses and cures.The comparison tools that work as compounding assets are the ones the audience trusts to help them decide. Not because the tool flatters the brand. Not because the tool dumps features. Because the tool genuinely helps the user pick the option that fits their situation, and is honest about which option that is.
That is the bar. Below the bar are feature-list-dump (no decision support; user leaves without choosing) and hidden-recommendation (biased pretending to be neutral; trust collapses when caught). Above the bar are honest-comparison-with-guidance tools where axis selection, default logic, recommendation engine, and filter UX work together to produce decisions the audience trusts.
The discipline is in the design choices. The decision to build a comparison at all. The axes that earn placement. The defaults that serve the audience. The recommendation that is visible and defended. The filters that help the user match their context. The methodology that is disclosed. The maintenance that keeps the comparison current.