Stats
Actions
Tags
From design-system-ops
Writes one-page stakeholder briefs translating design system health, status, or recommendations into business language for non-designer audiences. Useful for exec updates, leadership summaries, or status reports.
How this skill is triggered — by the user, by Claude, or both
Slash command
/design-system-ops:stakeholder-briefThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.
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.
The stakeholder brief workflow follows five distinct steps:
Ask for or confirm:
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."
Date: [date] Prepared by: [name] For: [audience] Regarding: [one-sentence description of the subject]
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.
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.
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.
The ask. One to three specific items. Each item should be concrete: a decision, a resource allocation, an approval, or a timeline confirmation.
Format:
No more than three items. A brief with six asks does not get any of them approved.
Two to three sentences. If the recommendation is followed and the ask is granted: what changes, when, and what does success look like?
Be honest about timelines and realistic about what the investment will and will not solve. Overpromising in a stakeholder brief erodes trust faster than almost anything else.
Different stakeholders care about different things. Adjust the brief's emphasis and language based on who is reading:
What matters: Technical debt, team velocity, engineering productivity, maintenance burden, system reliability.
How to frame it:
Specific language to use:
What to avoid:
What matters: User experience, feature velocity, customer satisfaction, time-to-market, competitive positioning.
How to frame it:
Specific language to use:
What to avoid:
What matters: Design quality, design team autonomy, consistency, scalability of design work.
How to frame it:
Specific language to use:
What to avoid:
What matters: Strategic alignment, risk mitigation, financial impact, competitive positioning, organisational efficiency.
How to frame it:
Specific language to use:
What to avoid:
The same situation can be framed three ways. Choose the frame that will resonate most with the audience and the context:
Use this framing when the situation is about enabling scale or speed.
Pattern: "We are currently [current state]. To [strategic goal], we need [investment]. This investment will [specific speed/scale benefit]."
Example: "We are currently building features through per-product design cycles. To scale to [n] products without proportionally scaling the design team, we need to formalize the design system. This investment will let us ship [n] new products using [n]% of the design effort currently required."
Works best for:
Use this framing when the situation involves technical or user-facing risk.
Pattern: "We are currently [current state], which creates [specific risk]. The cost of this risk is [impact]. We can eliminate this risk by [investment]."
Example: "We are currently using [n] accessibility implementations across [n] teams, each implemented differently. This creates legal compliance risk and excludes users with disabilities. We can eliminate this risk by centralizing accessibility implementation in the design system."
Works best for:
Use this framing when the situation involves efficiency or waste.
Pattern: "We are currently [current state], which costs us [specific financial or effort metric]. We can recover this cost by [investment]."
Example: "We are currently estimating [n] engineering weeks per quarter spent on duplicated component work across [n] teams. We can recover this cost by consolidating implementations, freeing up [effort or FTE] for product work."
Works best for:
Choose the frame that matches the audience's priorities:
Design system health metrics do not land with stakeholders unless they are translated into business consequences. Use this reference when writing the "Why this matters" section:
| Design system metric | Business translation |
|---|---|
| Low token adoption | "Visual inconsistency across products is creating a fragmented brand experience" |
| High component drift | "Teams are maintaining separate versions of the same interface elements, duplicating engineering effort" |
| Poor documentation coverage | "New team members take longer to become productive because system knowledge is tribal, not documented" |
| Low accessibility scores | "We have measurable compliance gaps that create legal exposure and exclude users with disabilities" |
| Declining adoption | "Teams are choosing to build independently rather than use shared infrastructure — the system is not serving their needs" |
| No AI-readiness | "Our component library cannot be consumed by AI development tools, which means we are not benefiting from AI-assisted coding workflows" |
| Version lag across teams | "Multiple teams are running outdated versions, which means bug fixes and improvements are not reaching users" |
| Missing governance process | "There is no defined process for how the system evolves, which creates unpredictability for teams that depend on it" |
When writing the brief, choose the 1–2 translations most relevant to the audience's priorities. Do not list all of them — a brief with eight business consequences reads as a list of complaints, not a focused argument.
At the staff level, stakeholder briefs should frame the design system as infrastructure, not as a design convenience. This changes how the situation, recommendation, and outcome are written.
If a system-health assessment has been completed, reference the maturity level in the brief. Frame the recommendation as moving from the current level to the next:
Infrastructure language:
Maturity level context:
Mapping maturity to investment:
Avoid these mistakes — they erode credibility faster than almost anything else:
The mistake: "The design system shipped 5 new components this quarter. Teams love the new Button variant. Component adoption is up 2%."
Why it fails: Readers detect cherry-picking. If you only mention wins, they wonder what you are hiding.
The fix: Lead with the honest situation — what is working and what is not. "The design system shipped 5 new components this quarter, bringing core coverage to 85%. However, adoption of the new components is only 40% in the first month, well below our target of 80%. This suggests the components are not meeting team needs or there is friction in the adoption process."
The mistake: "The component library has low token adoption and declining API consistency. We need to improve the design-to-code contract and implement automated drift detection."
Why it fails: Non-design audience stops reading and dismisses it as design-specific. You lose them in the first sentence.
The fix: Translate everything. "Teams are not using the shared design tokens consistently, which means interfaces look different across products even when they should look the same. We need to clarify how components should be built and automated tools to detect when they drift from the standard."
The mistake: "We need a dedicated design systems team. Please allocate 1 FTE."
Why it fails: Readers have no context for whether 1 FTE is reasonable. You are asking them to trust your judgment, but you have not given them the information to make the decision.
The fix: Show the math. "Teams are spending an estimated [n] weeks per quarter on duplicated work. Dedicating 1 FTE ([cost]) to system maintenance will recover [n] weeks of duplicated effort, paying for itself in [timeline]. Without this investment, the duplicated work continues to compound."
The mistake: "The design system has 92 components. 34% of teams are using it. Average component adoption time is 3.2 weeks."
Why it fails: Raw metrics mean nothing without context. Is 34% adoption good or bad? Is 3.2 weeks fast or slow? The reader has to guess your conclusion.
The fix: Interpret the data. "The design system has 92 components covering the core patterns most teams need. However, only 34% of teams are actively using the system — the rest are either unaware it exists or finding it difficult to adopt. The average adoption time of 3.2 weeks is longer than target, suggesting we need better documentation or training."
The mistake: Throughout the brief, references to multiple things being asked for — "We need governance," "We need a dedicated team," "We need better documentation," "We need tool investment."
Why it fails: A brief with six asks dilutes each one. The reader remembers none of them.
The fix: State three asks or fewer, and state them explicitly in the "What we need" section. Everything else in the brief should build the case for those three asks specifically.
The mistake: "This investment will eliminate all design inconsistencies, reduce feature shipping time by 50%, and solve all accessibility compliance gaps."
Why it fails: Unrealistic promises create expectation debt. When you ship and the promised outcomes do not fully materialise, you lose trust permanently.
The fix: Be honest and specific. "This investment will establish consistent interface standards that new teams can use as their baseline, reducing the time to design consistency for new products from [current] weeks to [new] weeks. It will not eliminate legacy inconsistencies — addressing those is a separate effort. It will prevent new inconsistencies from accumulating."
Before delivering the brief, verify all of these:
If this skill runs as part of a recurring workflow, configure it as follows:
skills:
stakeholder-brief:
trigger: "quarterly-governance-review" # or "on-demand"
audience: "engineering-leadership" # or "product-leadership", "design-leadership", "executive"
framing: "cost" # or "growth", "risk"
maturity_level: true # if a maturity assessment is available, reference it
include_anti_patterns_check: true # always include
For quarterly stakeholder briefs:
system-health completesAt the staff level, stakeholder briefs should frame the design system as infrastructure, not as a design convenience. This changes how the situation, recommendation, and outcome are written.
AI-readiness as a competitive/efficiency argument: If relevant to the organisation, include the AI-readiness angle: "Design systems that are machine-readable enable AI-assisted development — code generation, automated testing, and design-to-code workflows. Our current system is not structured for AI consumption. The proposed investment includes making the system machine-readable, which positions the organisation to benefit from AI tooling without a separate initiative."
A stakeholder brief is only valuable if it leads to a decision. The brief should:
If the brief does not result in a decision after 2 weeks, follow up: "I wanted to check whether you have questions about the brief, or whether we need to adjust the proposal."
If the decision is no: ask why. Often the objection is not what was addressed in the brief — the brief revealed a different constraint.
If the decision is yes: confirm what changed, document it as a decision record, and set up the follow-up communication for consuming teams.
npx claudepluginhub murphytrueman/design-system-opsGenerates design system investment pitches with business cases, ROI framing, and objection handling for leadership. Triggers on requests to justify or sell design systems.
Creates consulting-grade reports and executive presentations using SCQA/SCR structure, Pyramid Principle for strategic assessments, board decks, and due diligence.
Guides you through writing a human-centered design brief including challenge statements, audience definition, and stakeholder alignment.