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. 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 / reduce cost of production)
- Product quality improvements (improved UI consistency / customer satisfaction)
- Preparing for future product expansion (speed in design and development together)
Determine if your design system approach should be "build" or "buy"
When it makes sense to build
- Unique brand identity
- Special industry requirements
- Technical constraints
- Long‑term investment
See: When Designers Should Build a Custom Design System from Scratch
When it makes sense to buy/hybrid
- Speed to market
- Resource constraints
- Standard patterns/UI
- 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 (e.g., TailwindCSS styling + custom component library)
- Set clear boundaries and document decisions for stakeholder alignment
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:
- What are we building? Components, documentation, tools
- When will things be delivered? Milestones and sprints
- Who will have access? Team adoption timelines
Quarterly roadmap with component progress tracking and team goals.
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. The principles build on work by Nathan Curtis.
Examples of what we track and why
- Lifecycle status from proposal to production
- Design and development parity to prevent inconsistencies
- Documentation coverage to improve adoption
- Platform support across web/mobile
- Component categorization to prioritize foundations
- Overall progress visualization for immediate understanding
- Approval status for governance and quality control
- Links to resources like Figma and GitHub
Strategy 3: Establish momentum-driving 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)
- Focus on what was completed yesterday and what's planned for today
- Keep them to 10–15 minutes (aim for daily, minimum 3× weekly)
- Save deeper discussions for after the main standup; capture decisions for sprint recap
2. Sprint planning
Sprint planning connects roadmap items to actionable tasks.
- Have leads draft the initial sprint plan; team reviews and adjusts
- 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.
- Sprint summaries (goals set, completed, and outstanding)
- Design and development accomplishments
- Decision points requiring stakeholder input
- Items moving to next sprint and enhancement ticket status
4. Quarterly retrospectives and futurespectives
Deeper reflection helps maintain strategic alignment
- Team retrospectives: What's working, what isn't, and why
- Futurespectives: Use SCOR (Strengths, Challenges, Opportunities, Risks) or other frameworks such as SWOT, Start‑Stop‑Continue, Impact/Effort Matrix
- Strategic planning: Adjust approach based on learnings
5. Self‑serve documentation
Comprehensive documentation demonstrates maturity
- Level 1: Component functionality and properties
- Level 2: Usage guidelines and design philosophy
- Developer implementation guides
- Governance and contribution models
Grab our free design system governance model template for Figma.
6. Team engagement and continuous learning
- 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 and adapt as needed.
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.
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
- Get Started with Multi‑Tiered UI Kits for Design Systems
- Getting started with Design Tokens in Figma
- Figma Plugins for Better App Design Workflows
- Design System Management - Updates and Communication