/stakeholder-brief

name: stakeholder-brief
description: "Write a one-page stakeholder brief translating design system health or status into business language. Trigger when someone says: stakeholder update, exec brief, leadership summary, status report for leadership, system status for non-designers, write a brief for the business, or anything about communicating design system status to an audience that does not have a design systems background."
references:
  - ../../knowledge-notes/output-discipline.md

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.

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.

Workflow overview

The stakeholder brief workflow follows five distinct steps:

1. **Establish the brief's purpose** — Confirm the context and the single ask 2. **Structure and write the brief** — Build the five-part template with business framing 3. **Calibrate tone by audience** — Adjust language and emphasis for the specific stakeholder group 4. **Apply framing patterns** — Lead with the insight that resonates most 5. **Review for clarity and quality** — Ensure no jargon, verify the one-page constraint

---

Step 1: Establish the brief's purpose

Ask for or confirm:

• What is this brief for? (Status update / investment ask / specific recommendation / incident summary / launch announcement)
• 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?

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"). Avoid metrics that make a small system look weak by enterprise standards — "3 components" sounds unimpressive without context. Instead, lead with what those components cover: "Our component library handles 80% of our interface patterns, ensuring consistent experience across all product surfaces."

---

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]

---

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. If you do not, be honest about what is estimated and why the estimate is reasonable.

---

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