Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Design tradeoff analyzer

Analyzes 2-5 competing design options across user impact, engineering effort, design system coherence, accessibility, and speed to ship — scoring each dimension, surfacing hidden tradeoffs, and delivering a ranked…

download .md

Purpose

Turn a fuzzy "which way should we go?" design decision into a structured comparison — scoring each option across the dimensions that actually matter (user impact, engineering effort, design system coherence, accessibility, speed to ship), surfacing the tradeoffs that get missed in a quick gut call, and landing on a defensible recommendation you can take into a scoping or prioritization conversation.

When to Use

Invoke this skill when the user asks to:

  • Choose between 2-5 competing design directions or solutions
  • Decide whether to ship a quick version now or a fuller version later
  • Scope a feature down and figure out what to cut without breaking the experience
  • Justify a design decision to PM, eng, or design leadership
  • Weigh a custom component against reusing an existing design system pattern
  • Compare a polished ideal against what's realistically buildable this cycle

Inputs Required

Before starting, collect:

  • The decision: One sentence on what's being decided and why it matters now
  • The options: 2-5 design directions being compared, with a short description of each
  • Primary user goal: The job the user is trying to accomplish in this flow
  • Engineering context: Team capacity, deadline, and any known technical constraints
  • Design system state: What existing components/patterns are available; how strict the system is
  • Success signal: The metric or outcome that tells you the chosen option worked
  • Hard constraints: Anything non-negotiable — accessibility requirements, deadline, platform limits

If engineering context or success signal is missing, proceed with stated assumptions and flag them at the top of the output.

Instructions

Step 1: Frame the Decision

Restate the decision in one sentence and name the real constraint driving it (time, capacity, coherence, or risk). Most tradeoff calls are actually one constraint wearing a costume — identify it. State the primary user goal so every option is judged against the same target.

Step 2: Score Each Option Across 5 Dimensions

For every option, rate each dimension High / Medium / Low with one line of reasoning. Don't just assign a label — name the specific reason.

  • User Impact: How directly does this move the user toward their primary goal? High = removes friction or unlocks a job-to-be-done; Low = cosmetic or marginal. Watch for options that look impressive but don't change the user's outcome.
  • Engineering Effort: Relative build cost given the team and stack. High effort = new backend work, novel interactions, or unproven patterns; Low effort = composition of existing parts. Flag where effort is uncertain vs. known-high.
  • Design System Coherence: Does this reuse existing patterns or introduce a new one? High coherence = built from system primitives; Low = a one-off that creates a maintenance debt and a precedent others will copy.
  • Accessibility: Can this meet WCAG AA without heroics? High = standard accessible patterns; Low = custom interactions (drag, hover-only, complex focus management) that are hard to make accessible. Treat this as a near-veto, not a tiebreaker.
  • Speed to Ship: Calendar time to get something in front of users, including review and QA — distinct from raw engineering effort. A low-effort option can still be slow if it's blocked on dependencies.

Step 3: Surface the Hidden Tradeoffs

This is the core value. For each option, name what the score table doesn't show:

  • What you're trading away: The cost that isn't on the dimension list (future flexibility, consistency precedent, support burden, user trust).
  • Second-order effects: What this option forces later — a one-off component you'll maintain forever, a pattern competitors of this screen will now copy, a migration you're deferring.
  • The reversibility check: Label each option One-way door (expensive to undo) or Two-way door (cheap to reverse). Push hard on shipping two-way-door options fast and reserving deliberation for one-way doors.

Step 4: Build the Comparison Table

Produce a table: rows = options, columns = the 5 dimensions + Reversibility. Use High/Med/Low cells. This is the artifact the user pastes into a doc or shows in a review.

Step 5: Rank and Recommend

Rank the options 1 to N. Give one clear recommendation with a 2-3 sentence rationale tied to the constraint identified in Step 1 and the primary user goal. Be opinionated. Then add:

  • The honest cost of the recommendation: What you're knowingly giving up by choosing it.
  • The condition that would flip the call: "If the deadline moves two weeks, Option B becomes the right choice." This makes the recommendation durable when context shifts.

Step 6: Sequencing Note (When Relevant)

If a "ship now, improve later" path exists, lay out the phased version: what ships in v1, what's deferred, and the explicit signal that triggers the next phase. This often beats picking a single option outright.

Output Format

  • Structure: Decision frame → per-option scoring → hidden tradeoffs → comparison table → ranked recommendation → sequencing note
  • Length: 700–1,000 words
  • Format: Prose for framing and tradeoffs; a Markdown table for the dimension scoring; numbered ranking for the recommendation
  • Sections: Decision Frame → Option Scoring → Hidden Tradeoffs → Comparison Table → Recommendation → Sequencing (if applicable)
  • Tone: Senior IC designer reasoning out loud — decisive, concrete, willing to commit to a call without hedging

Quality Checklist

Before delivering output, verify:

  • [ ] Every option is scored across all 5 dimensions (count: options × 5 cells, each with a reason)
  • [ ] Each option has a reversibility label (One-way door / Two-way door)
  • [ ] At least one non-obvious tradeoff is surfaced per option — not just a restatement of the scores
  • [ ] The comparison table is present and includes all options as rows
  • [ ] A single ranked recommendation is made with a stated cost and a condition that would flip it
  • [ ] Any missing input is flagged as a stated assumption rather than silently filled in

Notes

  • The most common failure in design tradeoff calls is optimizing for "best design" over "right design for this constraint" — the Step 1 constraint frame prevents this.
  • Accessibility should function as a near-veto: an option that can't meet AA shouldn't win on speed or polish, no matter how attractive the other scores look.
  • "Two-way door" options deserve a bias toward shipping fast and learning — reserve deep deliberation for decisions that are expensive to reverse.
  • When two options score nearly identically, the tiebreaker is almost always design system coherence (lower long-term cost), not short-term speed.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills