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 decision communicator

Converts raw design rationale notes into a structured stakeholder-facing narrative that frames every decision in business terms — connecting each choice to user needs, business goals, and trade-offs, with anticipated…

download .md

Purpose

Turn a designer's internal rationale — scattered notes, gut calls, and craft-driven reasoning — into a clear, business-framed narrative that non-design stakeholders can follow and approve. Solves the recurring problem of great design work getting picked apart or rejected in reviews because the reasoning was never translated out of design language.

When to Use

Invoke this skill when the user asks to:

  • Prepare a design review or presentation for executives, PMs, or clients
  • Explain the reasoning behind a design decision to a non-designer
  • Turn design rationale notes into a talking-points doc or narrative
  • Pre-empt stakeholder objections before a critique or sign-off meeting
  • Justify a design trade-off (e.g., simplicity over feature density) in business terms
  • Get buy-in on a redesign, layout change, or flow revision

Inputs Required

Before starting, collect:

  • The design decisions: Raw notes, bullets, or descriptions of the choices made (layout, flow, component, interaction, visual)
  • What the design is for: The product, feature, or screen and what it's meant to accomplish
  • Stakeholder audience: Who's in the room — executives, PMs, engineers, marketing, clients (affects framing)
  • Business goal at stake: The metric or outcome this design is meant to influence (conversion, retention, activation, support-ticket reduction, etc.)
  • Known constraints: Technical, timeline, brand, or scope limits that shaped the decisions
  • Anticipated pushback: Objections the user expects, or past feedback on similar work

If the business goal is not provided, infer the most likely one from the product context and state the assumption explicitly.

Instructions

Step 1: Extract and Cluster the Decisions

Parse the rationale notes into discrete, named design decisions. Cluster related choices so the narrative flows around 4–8 core decisions, not 30 micro-details. For each decision, identify:

  • What changed / what was chosen (the observable design fact)
  • The craft reasoning (why a designer would do this)
  • The business translation (why a stakeholder should care)

Discard reasoning that is purely aesthetic preference with no user or business tie — or reframe it around what it enables.

Step 2: Translate Craft Reasoning into Business Language

For every decision, run the craft reasoning through this translation layer. Replace design-internal justifications with stakeholder-relevant ones:

  • "It's cleaner / more balanced" → "Reduces cognitive load so users complete the task faster"
  • "Better visual hierarchy" → "Directs attention to the primary action, lifting conversion on the key step"
  • "Follows the design system" → "Keeps the build fast and the experience consistent, reducing future rework"
  • "More whitespace" → "Makes the core value obvious in the first 3 seconds, when users decide to stay or leave"
  • "Progressive disclosure" → "Prevents overwhelming new users while keeping power features available"

Never leave a decision justified only by taste. Every one must connect to a user need, a business goal, or a reduced risk/cost.

Step 3: Frame Each Decision With the Trade-Off Named

Stakeholders trust designers more when trade-offs are stated openly rather than hidden. For each core decision, structure it as:

  • Decision: What was chosen, in one plain sentence
  • Why: The user + business rationale (2–3 sentences)
  • Trade-off: What was consciously given up and why that trade was worth it
  • Alternative considered: The most credible option that was rejected, and the reason

This pre-empts "why didn't you just..." questions by showing the alternatives were already weighed.

Step 4: Build the Opening Frame

Write a short opener (3–5 sentences) that anchors the whole review in the business goal — not the design. Lead with the problem the design solves and the outcome it's meant to move, so stakeholders evaluate the work against the right criteria from the first sentence.

Step 5: Pre-Answer Anticipated Objections

Create an objection-handling section. For each likely piece of pushback (from the user's input or predicted from the audience type), write:

  • The objection (in the stakeholder's own likely words)
  • The response (calm, non-defensive, evidence- or goal-anchored — one short paragraph)

Tune tone by audience: executives want outcome and risk; engineers want feasibility and scope; PMs want metric impact and prioritization; clients want alignment with their stated goals.

Step 6: Close With the Ask

End with a clear, single ask — sign-off, a specific decision, or scoped feedback ("feedback on the checkout flow, not the visual style — that's locked"). Ambiguous reviews produce ambiguous outcomes; name exactly what's needed to move forward.

Output Format

  • Structure: A presentation-ready narrative document, ordered as opener → core decisions → objections → the ask
  • Length: 700–1,100 words
  • Format: Structured prose with labeled decision blocks; objection section as paired objection/response items
  • Sections: Opening Frame → Core Design Decisions (4–8, each with Decision / Why / Trade-off / Alternative) → Anticipated Objections & Responses → The Ask
  • Tone: Confident and plain-spoken — a designer who leads the room, not one seeking approval. No design jargon left untranslated; no apologizing for choices.

Quality Checklist

Before delivering output, verify:

  • [ ] Every core decision connects to a user need, business goal, or reduced cost/risk — none justified by taste alone
  • [ ] Each decision block names an explicit trade-off and a rejected alternative
  • [ ] The opening frame leads with the business problem, not the design itself
  • [ ] The objections section addresses at least 3 pieces of pushback in the audience's own language
  • [ ] Zero untranslated design jargon (no "hierarchy," "balance," "affordance" left standing without a plain-language equivalent)
  • [ ] The document ends with a single, specific ask

Notes

  • The most common failure in design reviews is defending the work; this skill reframes it as explaining decisions against shared goals — a much stronger position.
  • When the audience is mixed (e.g., execs + engineers), lead the opener toward the highest-authority decision-maker and route engineer-specific concerns into the objections section.
  • If the rationale notes are thin or purely aesthetic, surface that gap directly: ask the user what user problem or metric the design was meant to move, rather than manufacturing a justification.
  • Naming a rejected alternative is disproportionately persuasive — it signals rigor and defuses second-guessing before it starts.

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