/system-pitch

name: system-pitch
description: "Investment pitch for a new or continuing design system: cost of current state, ROI with visible assumptions, objections, the ask. Triggers: pitch the system, business case, justify the investment, sell this to leadership. For a routine status update use stakeholder-brief."
allowed-tools: Read, Write, Grep, Glob, Bash(cat:*), Bash(ls:*)
references:
  - ../../knowledge-notes/executive-communication.md
  - ../../knowledge-notes/output-discipline.md

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.

Before you begin: verify references

Confirm that every path in this skill's frontmatter `references:` exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example `npx skills install`) dropped the repo-root `knowledge-notes/` directory. Tell the user to reinstall by a method in `1-INSTALL.md` and run `verify-install.sh` from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.

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.

Audience calibration, framing patterns, metric translation, anti-patterns and the numbers-honesty rules are shared with stakeholder-brief and live in the executive-communication note. This skill covers what is specific to an investment case.

Workflow overview

1. **Understand the context and gather evidence** — the situation, the audience, the likely objection, and what data exists 2. **Estimate the cost of the current state** — quantify the problem from labelled inputs 3. **Write the pitch** — the five-part template, problem first 4. **Calculate ROI and payback** — one loaded rate, recomputed arithmetic, visible assumptions 5. **Address the likely objections** — the four-step method 6. **Calibrate to the audience** — from the executive-communication note 7. **Choose the team model** — solitary, centralised or federated (Nathan Curtis's models) 8. **Frame the cost of inaction** — only from figures already sourced 9. **Quality checks**

---

Step 1: Understand the context and gather evidence

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")
• What data exists? (Time spent on inconsistent work, accessibility incident history, customer complaints about inconsistency, hiring plans, loaded salary rates)

If system-health or adoption-report output exists, use its figures and cite them. Claims about the user's system come from inspected files, prior skill output, or the user — never from what a typical organisation looks like. Anything the pitch needs and nobody can supply stays as `[needs data: …]`.

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. Every line is labelled measured, estimated (with reasoning) or assumed, and every hour is costed at the same loaded hourly rate used for the investment in Step 4.

Business metrics worksheet

**Loaded hourly rate (assumed, one rate for everything):** ___ — salary plus overheads, divided by working hours a year (2,080 for a 40-hour week)

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

• Engineers doing duplicated work: ___
• Estimated weeks per engineer per year on duplicated work: ___
• Annual cost: ___ engineers ×