Doing the work vs showing the value
You're deep in the weeds of design system work, carefully crafting components and documentation, when suddenly a message arrives from leadership:
"Could I get a design system progress update? Maybe send me some metrics?"
Panic sets in. You're not prepared for this conversation.
You might find yourself frantically switching between Figma screens during a Zoom call, giving everyone a case of "Figma whiplash" as you struggle to communicate your team's significant but hard-to-quantify progress.
Sound familiar? You're not alone.
Solving the mystery of knowing what and how to communicate
Unlike feature-driven teams, design system teams build foundational elements that aren't always easy to quantify or communicate. And there’s not a lot of resources out there to help with this issue.
Go from 'What are you doing?' to 'This is great!'
This guide provides actionable strategies to take those panic-inducing "Can I get an update?" moments into opportunities to showcase your team's impact.
I took everything from my video and broke it down into this article for you with links to resources and templates as I go through each section.
The root of this problem: different zoom levels
The Sims vs SimCity Perspective

Stakeholders view your work from a SimCity perspective - the big picture view.
Stakeholders operate at the "SimCity" level, concerned with infrastructure, resources, and outcomes. They see the entire city from above, focusing on whether neighborhoods have electricity and roads.

Design system teams operate at the Sims level - seeing every detail up close.
Your design system team works at "The Sims" level - seeing individual characters moving through rooms, eating breakfast, and interacting with specific objects. You're immersed in the details of component variants, tokens, and documentation.
This fundamental disconnect creates communication challenges
It’s not that you don’t understand the big picture, it’s that you need to know what not to share as much as what they want to see. It’s really easy to get caught up in the details of you work to justify time spent on something, but the details often go down unnecessary rabbit holes and make meetings go on longer than they need to.
To bridge this gap, we need strategies that translate your detailed work into stakeholder-friendly insights that align with their zoom level.
Strategy 1: Definition equals clarity
Aligning with organizational goals
Before diving into execution, establish clear definitions and scope that align with broader company objectives. When your design system directly connects to company priorities, conversations with stakeholders become easier because you're speaking the same language.
Connect your design system work to specific business outcomes
- Design efficiency (create mockups faster/reduce cost of production)
- Development efficiency (faster development process/reduce cost of production)
- Product quality improvements (improved UI consistency/customer satisfaction)
- Preparing for future product expansion (design system improves speed of design and development together)
- etc
Determine if your design system approach should be "build" (from scratch) or "buy" (leverage existing frameworks)
When it makes sense to build
- Unique brand identity
- Special industry requirements (unique UI)
- Technical constraints (Purchased kit wouldn’t work)
- Long-term investment (Expansive product or products over time)
When it makes sense to buy/hybrid
- Speed to market
- resource constraints
- standard patterns/UI (nothing special needed)
- Useful for MVP testing
Hybrid approach
- UI Kit with custom adjustments
- Gradual replacement of components over time
- Frameworks as a starting point
- Mix and match (TailwindCSS for styling + custom component library)
- Set clear boundaries for what is and isn't in scope and make sure they are agreed upon by all parties.
- Document these decisions for reference in stakeholder conversations
Strategy 2: Plan your route with a living roadmap

A design system roadmap isn't a one-time artifact—it's a living document that needs regular maintenance. When done right, it becomes a powerful communication tool that stakeholders can reference even when you're not in the room.
Your design system roadmap should answer three critical questions:
- What are we building? Components, documentation, tools
- When will things be delivered? Milestone dates and sprints
- Who will have access to those things? Team adoption timelines
Real-World Design System Roadmap Example

Quarterly roadmap with component progress tracking and team goals.
This visual representation helps stakeholders quickly understand both progress and trajectory, while accounting for team capacity changes.
An effective design system roadmap includes
Progress tracking for components (from a Component Tracking Matrix)
- Learn more about this further down in the next section.
Feedback and enhancement metrics.
- Separate your enhancements from team request volume. Your own enhancements might be variable to track.
- Decrease number of team requests, ideally decreasing over time. The less requests, the more effective the design system.
Monthly cards for design and development priorities
- Design goals (e.g., "Onboard product designers", "Finish contribution model")
- Development goals (e.g., "Write dev tool configuration docs")
Team capacity notes
- Important dates (e.g., "Dec 24th - Jan 2nd everyone is out of office")
Component Tracking Matrix
Our Component Tracking Matrix serves as a comprehensive view of design system progress across multiple dimensions. This matrix turns abstract progress into concrete metrics that both design system teams and stakeholders can reference, bridging the "zoom level" gap.
We leverage this template found from this comprehensive article by Wart Burggraaf on the topic. It all stems off of the foundational work by Natahan Curtis as seen in his original writings in 2010. The principles still ring true, even when the tools change!
We stand on the shoulders of giants because of the designers before us all.

Examples of what we track and why
- Component Status Across the Lifecycle - We track each component through its entire journey from proposal to production, allowing us to identify bottlenecks in our process
- Design and Development Parity - The matrix shows at a glance where design and code implementations are in sync or diverging, helping prevent inconsistencies
- Documentation Coverage - We explicitly track documentation completion because well-documented components are more likely to be adopted correctly
- Platform Support - Tracking which components work across web/mobile helps product teams understand availability for their specific platform needs
- Component Categorization - Organizing by component type (atoms, etc.) helps us prioritize foundational elements first
- Overall Progress Visualization - The progress bars provide stakeholders with an immediate visual understanding of completion status
- Approval Status - Tracking which components have passed review processes ensures quality control and helps with governance
- Linking to Resources - Direct links to Figma and GitHub implementations reduce friction for teams needing to access components


Strategy 3: Establish momentum-driving rituals

The building blocks of design system communication rituals
Success isn't just about what you build—it's about how you build it and communicate progress along the way. By establishing the right rituals, you create natural opportunities to showcase value.
1. Daily standups (10-15 minutes)

These quick, regular check-ins help your team stay aligned and identify collaboration needs:
- Focus on what was completed yesterday and what's planned for today
- Keep them to 10-15 minutes
- Aim for daily frequency (minimum 3x weekly)
- Save deeper discussions for after the main standup
- Try to keep track of decisions that come out of these meetings, so they can be referenced in your sprint recap.
2. Sprint planning

Sprint planning connects roadmap items to actionable tasks.
Bi-weekly sprint planning connects your roadmap to tactical execution:
- Have leads draft the initial sprint plan
- Team reviews and adjusts as needed
- Always connect sprint goals back to the roadmap
- Adapt planning style based on your current phase (building vs. refining)
3. Monthly leadership recaps

A structured monthly recap provides high-value information to stakeholders.
These structured updates provide consistent value to stakeholders:
Include:
- Sprint summaries (goals set, completed, and outstanding)
- Design team accomplishments (e.g., "Figma system is up and running")
- Development team accomplishments
- Decision points requiring stakeholder input or things the team decided on this sprint
- Items moving to next sprint
- Enhancement tickets and their status
This format provides a clear "too long; didn't read" summary for busy stakeholders while offering enough detail for meaningful conversation.
4. Quarterly retrospectives and futurespectives

The SCOR framework helps teams analyze Strengths, Challenges, Opportunities, and Risks.
Deeper reflection helps maintain strategic alignment
- Team retrospectives: What's working, what isn't, and why
- Futurespectives: For example, using the SCOR framework to analyze strengths, challenges, opportunities, and risks.
- There are other frameworks available for this exercise as well.
- SWOT Analysis
- Startp-Stop-Continue
- Impact/Effort Matrix
- There are other frameworks available for this exercise as well.
- Strategic planning: Adjust approach based on learnings
For example
The SCOR framework is particularly valuable for futurespectives, allowing your team to:
- Identify current strengths to build upon
- Acknowledge challenges that need addressing
- Discover opportunities for improvement
- Mitigate potential risks before they impact your work
5. Self-serve documentation

Well-structured documentation reduces questions and demonstrates system maturity.
Comprehensive documentation reduces questions and demonstrates maturity
- Level 1 documentation: Component functionality and properties
- Level 2 documentation: Usage guidelines and design philosophy
- Developer implementation guides
- Governance and contribution models

A clear governance model shows how decisions are made and contributions are managed.
Grab our free design system governance model template for Figma
The contribution model is particularly important as it:
- Shows stakeholders how the design system can scale beyond your team
- Creates clear pathways for others to participate
- Evolves as your system matures
6. Team engagement and continuous learning

Regular open office hours on your calendar create a dedicated space for questions and feedback.
Active community building increases adoption and demonstrates impact:
- Personal onboarding for new team members
- Weekly open office hours for questions and feedback
- Dedicated communication channels for design system updates
Being proactive to lead the way
Creating visibility, rather than waiting for stakeholders to ask for updates, positions your team as strategic rather than reactive.
Start with a few key activities that make sense for your organization. Not every ritual will work for every team—and that's okay! Adapt, remix, or replace activities that don't serve your specific context.
This proactive approach requires some upfront investment but can create tremendous returns in stakeholder trust and organizational alignment. By bringing clarity to different levels of the organization, your design system work can get the recognition and support it deserves.
Become a design system pro with our latest video course

We created a premium design system course for Figma.
It covers everything from planning, laying foundations, design tokens, developer handoffs, and more.
Everything you need to help lead your team with a clear design system process.
Free design system resources

Our Figma design system templates
- Design System Governance Template
- Design System Component Capture Template
- Type Scale Worksheet
- Design System Interview Template
- Design System Checklist
Learn from our crew
Intro to Design Systems Course for Product Teams
In this free course, learn how to build design systems that save you time, improve the quality of your product, and empower your team to go further faster.
Get Started with Multi-Tiered UI Kits for Design Systems
Learn how Multi-Tiered UI Kits can support multiple mini products that need to share similar themes & patterns under one brand and still create unique experiences.
Getting started with Design Tokens in Figma
An introduction to creating and managing design tokens in Figma to improve design hand-offs for development teams.
Figma Plugins for Better App Design Workflows
A growing list of our favorite Figma plugins and how they fit into our process at Headway.
Design System Management - Updates and Communication
The step-by-step process we use at Headway to keep our design systems up to date between design and development teams.