Stakeholder Brief

Stakeholder brief

A skill for writing a one-page stakeholder brief that translates design system health, status, or a specific recommendation into business language. Output requires no design systems knowledge to read, leads with business impact, and ends with a clear ask.

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 systems teams are often better at building systems than at communicating their value to the people who fund and prioritise them. The result is that design systems work gets under-resourced, and the case for investment gets made reactively — when something breaks — rather than proactively, when there is time to think clearly.

A stakeholder brief is not a technical report with a summary at the top. It is a business communication that happens to be about design systems work. The reader should be able to understand the situation, the recommendation, and the ask without any prior knowledge of what a design system is or how it works. If a term requires explanation, the explanation belongs in the brief, not in a separate glossary.

Audience calibration, framing patterns, metric translation, anti-patterns and the numbers-honesty rules are shared with system-pitch and live in the executive-communication note.

Workflow overview

1. Establish the brief's purpose — Confirm the context, the sources and the single ask
2. Write the brief — The five-part template with business framing
3. Calibrate to the audience and choose the frame — From the executive-communication note
4. Frame maturity (staff-level) — Named stages and the next transition, when an assessment exists
5. Quality checks — No jargon, one page, every figure sourced

---

Step 1: Establish the brief's purpose

Ask for or confirm:

• What is this brief for? (Status update / specific recommendation / incident summary / launch announcement). A full investment case with cost of current state and ROI is a pitch, not a brief — use system-pitch.
• Who is the primary audience? (VP, C-suite, product director, budget owner — this determines the level of business abstraction)
• What is the one thing the reader should do or believe after reading it?
• What is the underlying situation? (Health report findings, a specific blocker, a proposed investment, a recent achievement)
• Is there a deadline or decision this brief is feeding into?
• What are the sources? If system-health, adoption-report or other skill output exists, use its figures and cite it. Facts about the system come from those outputs, inspected files, or the user; anything else stays as [needs data: …].

The brief should have a single primary purpose. A brief that tries to deliver a status update and make an investment ask and announce a new feature is three briefs, and it will not do any of them well.

Small-system note (fewer than 5 components): For systems with fewer than 5 components, the brief needs to frame the system as a deliberate, focused investment rather than something that is small because it is under-resourced. Use "specialised system" or "targeted component library" framing. The ROI argument shifts from scale efficiency ("20 teams reuse the same components") to quality consistency ("every customer-facing surface uses the same interaction patterns") and speed ("new features compose from proven components instead of starting from scratch"). Give the size plainly and give it context in the same sentence: "three components, covering [share of interface patterns, from an inventory or audit]". Choosing which true figures to show is framing; leaving out a figure because it sounds small is the "only good news" anti-pattern in the executive-communication note, and a reader who later learns the number stops trusting the brief.

---

Step 2: Write the brief using the five-part template

---

[Brief title — describes the situation and the ask in plain language]

Date: [date] Prepared by: [name] For: [audience] Regarding: [one-sentence description of the subject] Open placeholders: [every [needs data: …] left in the brief, or "none"]

---

The situation

Two to four sentences. What is the current state of affairs that makes this brief necessary? Write in terms of business impact, not design system mechanics.

Not: "The design system has 42 components and a 60% engineering adoption rate across product teams." But: "Three product teams are currently maintaining separate, inconsistent versions of core interface components. This creates inconsistent customer experiences and duplicates development effort across the organisation."

If the situation requires a brief explanation of what a design system is: include one sentence. Do not assume the reader knows. Do not patronise them with a long explanation. "A design system is the shared library of interface components and visual standards that product teams use to build consistently without building from scratch each time" is usually sufficient.

---

Why this matters

Two to three sentences. What is the business consequence of the situation? Translate into the currency that matters to this audience: time, money, customer experience, risk, competitive position.

Avoid design system metrics as the evidence of impact. "Low token adoption" is not a business problem. "Inconsistent interfaces are generating support tickets and reducing customer trust" is a business problem. Find the business translation.

If you have data, use it and name its source. If you do not, label the figure as estimated and show why the estimate is reasonable, or leave [needs data: …]. Derived figures (FTE equivalents, totals) are recomputed from the inputs shown.

---

What we recommend

One sentence stating the recommendation. Then two to four sentences explaining why this recommendation over the alternatives.

Be specific. "Invest in the design system" is not a recommendation. "Dedicate one engineering day per sprint to design system integration across the three product teams, for the next two quarters, to consolidate the parallel component implementations" is a recommendation.

If there are alternatives, acknowledge the most plausible one and explain why the recommendation is preferred. A brief that presents only one option looks like it has not considered the problem fully.

---