| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 080, deep dive hosted on August 28, 2026 with Ben Callahan, Robin Di Capua, and Taylor Cashdan. 👏 This episode is made possible by Dessn. Design in production. With Dessn, you can bring your entire team into production, in one click. Create high-fidelity prototypes from the first prompt. 👏 There are 52 answers. The question this week was: ----- Hello, system thinkers! Last week, I sat down with Robin Di Capua and Taylor Cashdan to talk through the origin story of the Redwoods Compass, a tool they’ve built to answer the question, “How is your design system program actually doing?” Months of intentional iteration and a strong sense that this thing should NOT “grade” your system have gotten them to this point—ready for you to try it out! The Compass isn’t a maturity model. There is no right answer or grade at the end. Instead, it’s closer to a Myers-Briggs for design systems. It’s a picture of where you are and the raw material for great discussion. This week is a little different from other episodes. We’re going to be talking about design system health and maturity, and the difference between them. And, we’re opening up The Redwoods Compass to you to try out. Welcome to episode 080 of The Question, with Ben Callahan, Robin Di Capua, and Taylor Cashdan on Visualizing Design System Health! Questions: What methods or tools do you use today to gauge, measure, or monitor the “health” of your design system? What has prevented your team from having an honest conversation about your design system’s health? • Disagreement about what “healthy” means • Fear of exposing weaknesses to leadership • Too busy to make time for it • Nothing, we do this regularly • N/A or Other (please explain) Homework: Please download this blank spider chart and plot your design system’s health to the best of your ability. Bring a digital image of this to the deep dive to drop into the FigJam. | |||||||||||||||||||||||||
2 | Question 1: What methods or tools do you use today to measure or monitor the “health” of your design system? | Question 2: What has prevented your team from having an honest conversation about your design system’s health? (select all that apply) | ||||||||||||||||||||||||
3 | A custom built analytics dashboard of consumers, which also includes an AI-generated audit of the code system vs. Figma in terms of tokens, visuals within components, layouts etc. | Too busy to make time for it,Team being refocused on other projects for considerable lengths of time | ||||||||||||||||||||||||
4 | We use library analytics in Figma as our primary source for component usage. More recently we’ve added using Claude to help answer specific questions that analytics doesn’t cover | Fear of exposing weaknesses to leadership,Too busy to make time for it | ||||||||||||||||||||||||
5 | Inserts and teams in Figma for design adoption, npm install data for engineering adoption, 2 question surveys during rituals for satisfaction and gap analysis, jira dashboard for SLA drift analysis, jira dashboard for governance utilization, teams engagement dashboard. | Nothing, we do this regularly | ||||||||||||||||||||||||
6 | Team member (consumer/contributor) surveys, design system team workshops, component health evaluations, linting and tests. | Nothing, we do this regularly | ||||||||||||||||||||||||
7 | No | Disagreement about what "healthy" means | ||||||||||||||||||||||||
8 | We don't have a great method to be honest, we track community sentiment via surveys every 6 months, and have an ongoing tracker for tickets/epics completed. We are trying to implement for strict analytics such as design system alignment, but its not going well. | Too busy to make time for it | ||||||||||||||||||||||||
9 | Figma Library Analytics API, Omlet, Jira queries tracking bugs | Early in our journey -- still trying to get dashboards and baselines established. | ||||||||||||||||||||||||
10 | I built an internal tool that tracks DS adoption and usage across two dozen product repos. Our DS is largely based upon the Mantine component library so we are also measuring the alignment between our Figma Design Library representation against the components actually used in the apps. We're still early, but healthy probably looks like all products building against a Figma design using the DS; applying the approved design tokens, components and custom variants which should result in a consistent, cohesive UI across the platform. | Disagreement about what "healthy" means,We're still early in DS development so we'll eventually get to the point where the DS is "mature" enough to heavily push adoption. We currently have just a few early adopters in our DS pilot. | ||||||||||||||||||||||||
11 | I wish we had better metrics, it’s currently vague number about which product teams are adopting and how much engagement we get in our channels. Even detailed stats on the code side don’t really tell the truth. | Disagreement about what "healthy" means,Too busy to make time for it | ||||||||||||||||||||||||
12 | I'm not sure we do honestly | Too busy to make time for it | ||||||||||||||||||||||||
13 | Nothing at the moment | Fear of exposing weaknesses to leadership | ||||||||||||||||||||||||
14 | Annual surveys and user interviews, Figma analytics, and a home-built code side analytics tool. | Too busy to make time for it | ||||||||||||||||||||||||
15 | Surveys, audits, page traffic | Nothing, we do this regularly | ||||||||||||||||||||||||
16 | Combination of using AI (MCP servers) to scan code and Figma to audit/find gaps, with human review. | Nothing, we do this regularly | ||||||||||||||||||||||||
17 | I suppose it depends on how we're defining "health." There are aspects we don't, or can't, measure. There are qualitative tools, like surveys, that we run too infrequently for fear of annoying consumers. And then there are things we have a hard time measuring like product impact, design and development efficiency, and improved product quality. | Too busy to make time for it | ||||||||||||||||||||||||
18 | Not implemented yet, but we've defined this as a goal to create the framework in the next year. | Too busy to make time for it | ||||||||||||||||||||||||
19 | Tools like Omlet, in-house, and recently a lot of AI audits. | Too busy to make time for it | ||||||||||||||||||||||||
20 | This is all in reference to component libraries I've helped build or have consumed in the past: I'm used to this measure being defined in terms of developer experience for consumers. In prior experiences, there usually wasn't time to diagnose or treat issues with the design system after its initial architecture. I can't say I've worked on project teams that used tooling specifically for this purpose. Usually, surfacing pain points is about as far as the conversation goes. | Disagreement about what "healthy" means,Too busy to make time for it | ||||||||||||||||||||||||
21 | I’ve recently been running a couple AI audit tools by Brad Frost and Murphy Trueman, and that’s been really helpful. | Disagreement about what "healthy" means,Feels a little overwhelming. Not sure where to start. | ||||||||||||||||||||||||
22 | Honestly, we don't have any focus on measuring the health of our design system today. We're so busy getting by and due to a lot of organizational and team changes along with larger strategic changes, we haven't had the time to make it a priority. We were in the middle of creating an adoption dashboard, planning for integration tracking, and occasionally looking at Figma analytics before that. | Too busy to make time for it | ||||||||||||||||||||||||
23 | Figma analytics, surveys | Too busy to make time for it | ||||||||||||||||||||||||
24 | Right now we don't have anything formal tools. We are having meetings and workshops with users when we need input. We also have something called a Hopes and Fears survey: we used it as a measurement of sentiment from before the DS launched and we update it every year to get metrics. | Just not there yet since we just launched. | ||||||||||||||||||||||||
25 | in github and ADO I'm looking manually at PR counts and progress and feature-level movement, plus any blockers. Then I made a metrics Rideshare app to weekly update with metrics around external adoption and customization of our tokens and components, combined with more insights about our internal component and token work progress, dependencies, skills usage, and opportunities for us to reach out to external teams to help them course-correct (customizing when we have a token or prop for that) or signals for component enhancements or new token sets | Too busy to make time for it | ||||||||||||||||||||||||
26 | No formal health metrics. A CI/CD check blocks any custom tokens or components outside the design system. Otherwise it's manual and reactive. | No defined health metrics to rally around and no dedicated capacity to build them. | ||||||||||||||||||||||||
27 | Views of docs website, usage internally, access to external funding | Nothing, we do this regularly | ||||||||||||||||||||||||
28 | At this point it's still verbal/informal/observational. We're investigating more objective tooling to track usage and such, but have yet to find something that'll work well for us. May have to build our own tools due to our multi-framework system. | Nothing, we do this regularly | ||||||||||||||||||||||||
29 | A yearly designer and developer sentiment survey is maybe the closest thing that comes to mind. | Really never thought about what design system health means. | ||||||||||||||||||||||||
30 | We have a dashboard that shows us all design system component usage, deprecated component usage, as well as the # of style overrides and lint violations over time. We've set up alerts to warn us when deprecated component usage or style overrides increase over a certain threshold. | Fear of exposing weaknesses to leadership | ||||||||||||||||||||||||
31 | n/a | Too busy to make time for it | ||||||||||||||||||||||||
32 | In the past we have used surveys, searching through code we have access to understand usage (we even tried scripting this at one point), general data points from feedback, when components didn't meet the needs, etc. | Nothing, we do this regularly,Too busy to make time for it | ||||||||||||||||||||||||
33 | Qualitatitive prototype research | Too busy to make time for it | ||||||||||||||||||||||||
34 | Vibes :) We routinely temperature-check how our design system is helping or hindering our designers, and evaluate our processes/prioritization. | True measurement using data (like adoption rates, etc) doesn't seem to fully capture a design system's effectiveness. | ||||||||||||||||||||||||
35 | N/A | Not currently managing any design systems. All previous experiences have been “you don’t have a design system, let’s start there” | ||||||||||||||||||||||||
36 | I don't believe we do | Too busy to make time for it | ||||||||||||||||||||||||
37 | Figma analytics, tracking usage on GitHub, Jira tickets (bug reports team submissions), qualitative feedback from the team | Nothing, we do this regularly | ||||||||||||||||||||||||
38 | adoption by platform, usage by component, NPS - user sentiment, number of components "on the shelf" | Disagreement about what "healthy" means,lack of clarity on goals, definition of success and definition of health | ||||||||||||||||||||||||
39 | Scan consuming repos, quant/qual studies | Nothing, we do this regularly | ||||||||||||||||||||||||
40 | Tools first. A documented minimum standard audit every component passes before release. Coverage tracked against an atomic inventory, currently 37 components. Docs engagement analytics. Figma library usage. And we've just installed code tracking in the core codebase to see what share of it actually uses our components. Writing that out, I notice all five measure the artefact. Quality, coverage, traffic, usage. None tell me whether the programme is healthy. The signals I'd actually call health, I don't measure. Adoption runs on an organisational mandate, so our usage numbers report compliance rather than pull. I have no idea how many teams would choose us if they didn't have to. And because we're open source, most of our consumers are people I can't convene, survey or interview, so the contribution and sentiment loops sit exactly where I have least access. | The numbers get used to justify the investment. Once coverage and component counts are the evidence for funding, admitting fragility costs you something. So the reporting stays on metrics that go up. | ||||||||||||||||||||||||
41 | We don't measure it. | Disagreement about what "healthy" means | ||||||||||||||||||||||||
42 | No a priority for us, quantitative via Figma metrics and code, but a lot has been qualitative these days, which isn't always in our favour. | Too busy to make time for it | ||||||||||||||||||||||||
43 | We experimented with Zeroheight's metrics, but haven't setup the automated portion yet. Not really a measure of health, more of adoption. If I were to assess my org's design system health, I'd describe it as a 60 year old man in a wheelchair chain smoking while on dialysis. | Too busy to make time for it | ||||||||||||||||||||||||
44 | Storybook metrics. Figma and code audits of deprecated or legacy components. Just also keeping our eyes and ears open on design regarding general understanding and adoption. | Too busy to make time for it | ||||||||||||||||||||||||
45 | Evaluate parity/drift between code and design: code connect, coverage (figma/code/npm) Adoption: weekly npm downloads, Figma library analytics API (measure activity outside core team), self-reporting usage mechanism Documentation: parity between Figma, Reference Site, CEM (which powers intellisense and MCP server) Contributions: GitHub discussions, issues, and feature requests; participation in the DS channel Feedback: Bi-weekly office hours feedback; Ad-hoc meetings with active teams regularly to understand positive and negative feedback Leadership support: Is the DS being included in vendor requirements, in policy documents, in AI code-assist initiatives; is it being brought up to executives as enablement? | Too busy to make time for it | ||||||||||||||||||||||||
46 | We don’t have a tool or method lately, in the past surveys have been sent out. | Too busy to make time for it | ||||||||||||||||||||||||
47 | We send surveys regularly to capture user sentiment. Our consumers are not bashful with their feedback, which is nice. On top of that, we also run an AI readiness audit on our system's repo. | Nothing, we do this regularly | ||||||||||||||||||||||||
48 | Code adoption metrics - a custom AST code scanner that runs twice a month with AI powered reports that consume the raw data. Annual satisfaction surveys for designers. | Too busy to make time for it | ||||||||||||||||||||||||
49 | We currently don't have a great way to measure or monitor the "health" of the design system. Teams within the org can use any technology or tooling they would like which has made it difficult to get adequate health data in an automated way. We relay heavily on consuming teams input and office hours as our monitoring system for overall health. | Too busy to make time for it | ||||||||||||||||||||||||
50 | It's still so early right now in the process, that I sort of measure it based on if my documentation is answering or creating questions for our dev team, and adjust accordingly. | I'm the only one that seems concerned with it at the moment | ||||||||||||||||||||||||
51 | Vibes :) We regularly temperature check how the design system is performing according to its usefulness for our designers. BUT we do not track adoption rates, etc. | Disagreement about what "healthy" means | ||||||||||||||||||||||||
52 | N/A | Access to the data we needed at was always a challenge as that data belonged to teams rather than us. | ||||||||||||||||||||||||
53 | customer support questions, PRs, requests, broader meeting venues, download metrics | Too busy to make time for it | ||||||||||||||||||||||||
54 | Feedback surveys | Too busy to make time for it | ||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||