/system-pitch

name: system-pitch
description: "Write a design system investment pitch with a business case and ROI framing. Trigger when someone says: pitch the design system, make the case for the system, sell this to leadership, justify the investment, business case for design systems, why should we invest in a design system, or anything about building an argument for design system investment or continuation."

System pitch

A skill for writing a design system investment pitch that leads with a business problem, builds an honest ROI case, and addresses likely objections. Output is a pitch document that works for an audience who has never heard of a design system and does not need to.

Context

Design system pitches usually fail for one of two reasons. They lead with the design system — its components, its tokens, its Storybook — rather than with the business problem it solves. Or they oversell: promising a design system will solve problems it cannot solve, which creates scepticism or, worse, expectation debt that damages credibility when the system ships and the promised outcomes do not materialise.

The pitch that works leads with the cost of the current state. It makes the reader feel the friction of inconsistency, the waste of duplicated effort, the risk of inaccessible interfaces — before it introduces the design system as the solution. Then it is specific about what the investment costs, honest about the timeline, and precise about what success looks like.

Workflow overview

The system pitch workflow follows seven distinct steps:

1. **Understand the context** — Assess the situation and likely objections 2. **Estimate the cost of the current state** — Quantify the problem 3. **Structure and write the pitch** — Build the five-part template with business framing 4. **Calculate and present ROI** — Show the financial return 5. **Address likely objections** — Preempt the 5–7 most common objections 6. **Frame by audience** — Calibrate the pitch for different stakeholders 7. **Review for clarity and quality** — Ensure the pitch leads with problem, not solution

---

Step 1: Understand the context

Ask for or confirm:

• Is this a pitch for a new design system, or a pitch to continue investing in an existing one?
• What is the current state? (Multiple teams building the same things independently / an existing system with low adoption / no system at all)
• What is the organisation? (Size, product count, team structure)
• Who is the audience for this pitch? (Executive, product leadership, engineering leadership, combined)
• What is the likely objection? (Cost, timeline, team capacity, "we tried this before")
• Is there any existing data available? (Time spent on inconsistent work, accessibility incident history, customer complaints about inconsistency)

The "likely objection" is important. A pitch that does not address the elephant in the room leaves the reader thinking about it instead of engaging with the argument.

**Small-system note (fewer than 5 components):** For small teams or products, the pitch faces a different objection: "Why do we need a design system? Can't we just coordinate?" The answer is that coordination without a system is coordination without a contract — it works until someone is on holiday, until a new team member joins, or until the product grows past the point where everyone can hold the conventions in their heads. The ROI framing shifts from "eliminate duplicated effort across 20 teams" to "protect consistency as the team grows, reduce onboarding time for new designers and developers, and make accessibility compliance a default rather than a per-feature effort." If the system already exists at this size, the pitch is usually for continued investment or formalisation — frame the ask around what has already been achieved informally and why it is worth making durable.

---

Step 2: Estimate the cost of the current state

Before writing the pitch, estimate the cost of the current state. These numbers power the "cost of the current state" section and make the ROI argument concrete.

Business metrics worksheet

Use this worksheet to gather the data you will need:

**1. Duplicated effort:** How many teams are independently building the same UI patterns?

• Teams: ___
• Estimated hours per team per quarter on duplicated work: ___
• Estimated cost: ___ teams × ___ hours × hourly rate = ___/quarter
• Annual cost: ___ × 4 quarters = ___/year

**2. Inconsistency cost:** How many customer-facing inconsistencies exist?

• Known support tickets related to UI inconsistency: ___
• Estimated support cost per ticket: ___
• Estimated customer churn impact from inconsistency: [qualitative or quantitative]
• Customer trust/brand impact: [qualitative assessment]

**3. Onboarding cost:** How long does it take a new designer/developer to learn current conventions?

• Current onboarding time for conventions: ___ days
• Estimated onboarding time with a documented system: ___ days
• Savings per new hire: ___ days × daily rate = ___
• Hires per year: ___
• Annual savings: ___ × ___ = ___/year

**4. Accessibility risk:** What is the current compliance state?

• Known accessibility violations: ___
• Estimated remediation cost if addressed per-product: ___
• Estimated remediation cost if addressed at system level: ___
• Potential legal/reputational cost of continued non-compliance: [estimate]

**5. Speed cost:** How much longer do features take without shared components?

• Estimated additional time per feature: ___ days
• Features shipped per quarter: ___
• Total additional cost: ___ days × ___ features × daily rate = ___/quarter
• Annual cost: ___ × 4 quarters = ___/year

**6. Competitive positioning:** Are competitors shipping faster or with more consistent experiences?

• Time-to-market comparison: [our product vs. competitor]
• Estimated impact on market position: [qualitative]

Not all of these will have hard number