| 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 074, deep dive hosted on May 7, 2026 with Ben Callahan and Kaelig Deloumeau-Prigent. There are 78 answers. The question this week was: ----- Hello, system thinkers! Last week, Kaelig and I were talking about one of the oldest frustrations in design systems work: visibility. For years, practitioners have wanted to know how their components are actually being used in the wild and for years, it’s been tough to do that. During our chat, Kaelig told me about a design systems symposium from 2016 with teams from Salesforce, GE, and a few other enterprise systems teams. To close that day, someone asked: "If you had a magic wand, what's the one thing you'd change about your design system?" Kaelig’s answer back then was tracking—he wanted discovery and visibility into how components were being used across his products. A decade later, that problem hasn't gone away. If anything, AI is making it more acute. The same forces that are giving design system teams more reach (skills, agents, automation, etc.) are also multiplying what's being created at a pace no team can manually review. And there’s a dark side to this. Our instinct to gain more visibility can easily tip into policing, which is the last relationship design systems teams want to have with their consumers. This week, we want to talk about the reality that AI may be shipping UI faster than we can review it, and how the enforcement-vs-enablement dial we've been tuning for years doesn't work in quite the same ways it has. Welcome to Episode 074 of The Question, with Ben Callahan and Kaelig Deloumeau-Prigent! How would you describe your current level of visibility into how your design system assets are actually being used across disciplines (including their use by AI)? (Select one) • We have robust, automated tracking and analytics • We have some manual processes or partial tooling • We rely mostly on informal channels (Slack, office hours, etc.) • We have very little visibility, it's largely a black box • N/A or Other (please explain) As AI agents and automation tools produce more content, design, and code at scale, what are your biggest design system concerns? (Select all that apply) • The system being used incorrectly or out of context • New patterns emerging that we can't see • Inconsistency accumulating faster than we can detect • Losing the feedback loops that inform system evolution • N/A or Other (please explain) How has your feeling about the right balance between design system enforcement and enablement shifted as AI enters the picture? (Select one) • Shifted significantly toward more enforcement • Shifted slightly toward more enforcement • Stayed about the same • Shifted slightly toward more enablement • Shifted significantly toward more enablement If you could instantly implement one thing today to improve visibility into how your system is actually being used (without becoming the "design police") what would it be and why? | |||||||||||||||||||||||||
2 | Question 1: How would you describe your current level of visibility into how your design system is actually being used across disciplines (including their use by AI)? (Select one) | Question 2: As AI agents and automation tools produce more content, design, and code at scale, what are your biggest design system concerns? (Select all that apply) | Question 3: How has your feeling about the right balance between design system enforcement and enablement shifted as AI enters the picture? (Select one) | Question 4: If you could instantly implement one thing today to improve visibility into how your system is actually being used (without becoming the "design police") what would it be and why? | ||||||||||||||||||||||
3 | We have robust, automated tracking and analytics | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enablement | Better understand of how components are being overridden. What are the changes people are making? Are many people commonly overriding the same thing, should this be the default? | ||||||||||||||||||||||
4 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,Ai hallucinating, inventing the guidelines | Shifted significantly toward more enforcement | 1. Automated tracing where custom implementation can be replaced by design system components. Why: we see every so often custom components popping up. Mostly when teams decide to build in business logic into UI layer. 2. Tracking Use of components and components properties, including overrides to detect new patterns/need from the teams 3. Direct diversion from a11y requirements where those are “advisory” and cannot be detected by current QA | ||||||||||||||||||||||
5 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted significantly toward more enforcement | Editting privileges for everyone but with guard rails in place | ||||||||||||||||||||||
6 | We have very little visibility, it's largely a black box | Inconsistency accumulating faster than we can detect,The system being used incorrectly or out of context | Shifted significantly toward more enforcement | Tracking across Figma designs and also code implementation of products and being able to have data on patterns usage, which components are used together with others, which components are overridden with specific values. This could be accessed by the DS team to do research and analysis to improve the system | ||||||||||||||||||||||
7 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Stayed about the same | Everything begins with knowledge for me. Enforcing or enabling comes best when I know what I'm dealing with and can make the right judgement calls. So more than anything id like to be able to tag or care of what goes out the door so I can work through enforcement or flexing the system with consumers | ||||||||||||||||||||||
8 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | I’m not sure yet! We are still getting some ai readiness into place. | For my team and org as it sits right now, I would be great to see how much of our design system actually makes it into prod. Our designer are using the Figma sources but how good is a branded design system if it’s not making into prod? It’s not to assign blame, but the metrics would quantify the drift in the larger org which would create opportunities to improve if we decided it. | ||||||||||||||||||||||
9 | N/A | N/A | N/A | N/A | ||||||||||||||||||||||
10 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | I've already built a repo scanner script that detects component usage. It is now being evolved into an automated standalone app. I'd like to see this tool being used to reliably track DS adoption. | ||||||||||||||||||||||
11 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | Very often and as an example 3 different designer might be thinking 3 different things for a similar problem that could use a single solution. Magic wand desire - Improve visibility between the DS consumers a.k.a innovators. That AI be able to detect and signal similar modifications or solutions that were say created by another designer already and it helps build a catalogue of 'DS border' components and their re-usability signals contributions to the DS rather than intensive independent conversation (if they even happen) | ||||||||||||||||||||||
12 | We have some manual processes or partial tooling | The system being used incorrectly or out of context | Shifted significantly toward more enablement | A static analysis of consuming projects that updates when code is merged that reports component usage. | ||||||||||||||||||||||
13 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted significantly toward more enablement | It would be visibility for others, not necessarily the team. Whether that be linting or some sort of easy mechanism for them to see other implementations that inspire their own. | ||||||||||||||||||||||
14 | We rely mostly on informal channels (Slack, office hours, etc.) | The system being used incorrectly or out of context | Shifted slightly toward more enforcement | Mandatory Onboarding session when a team starts using the system, and when they start using it with AI. Providing more education upfront helps teams to understand how to use things, and where to come for help, before they even getting started. 80% of situations where we have felt the need to "police" has more to do with people just not knowing or understanding rather than willfully choosing not to follow system standards. | ||||||||||||||||||||||
15 | We have very little visibility, it's largely a black box | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution | Shifted significantly toward more enforcement | I would love to conduct user research, much like we do for products and sites. Too often teams assume that because our folks know how to use components/tools that they don't need the effort to make it more usable for them. Design systems are complex and learning how they are used helps us make them better for the teams using them. | ||||||||||||||||||||||
16 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution | Shifted significantly toward more enablement | I want to quick way to see, analyze, and act on the range of compositions happening within our ecosystem, so that I can extract additional components that the system could offer as well as understand how custom styling is being appropriately applied to achieve one off goals | ||||||||||||||||||||||
17 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,The system being used incorrectly or out of context | Stayed about the same | Component tracking within our company's codebase so we can see specifically which applications are using which components/props/etc. as well as what other libraries they are pulling in | ||||||||||||||||||||||
18 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect | Shifted significantly toward more enablement | more data on usage, both in terms of numbers and visual / live examples | ||||||||||||||||||||||
19 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | Accurate measurement of per project coverage of the design system. | ||||||||||||||||||||||
20 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see | Both: enabling non-engineers to prototype and enforcing product teams to use our AI tooling for more compliant output. | How much of the output from a one-shot prompt leveraging our AI tools is usable in production as-is? | ||||||||||||||||||||||
21 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted significantly toward more enablement | We have tooling that passively scan front-end repos. Would love to enhance that with more active ones that AI logs as it builds. | ||||||||||||||||||||||
22 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,The system being used incorrectly or out of context | I can't really answer this one, as I integrate AI in my practice, but they are not yet integrated in the design system I'm working on because on budgets and internal policies (welcome to france) | Gotrino - Dan Donald DS Health Dashboard that gives you the big picture on your DS where you can dig for each components, patterns, informations tokens etc etc. Having a macro view and the possibility to dig into micro views ! | ||||||||||||||||||||||
23 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Stayed about the same | With zeroheight, I can see which repos are using components and tokens, but it's just a list. I can't see where these are being used. I wish I had more insight into exactly where everything is appearing. Right now, I just do a manual audit to see if anything looks off. Using dark mode is a good way to find places where tokens aren't being used correctly, but I am probably missing things. | ||||||||||||||||||||||
24 | We have some manual processes or partial tooling | The system being used incorrectly or out of context | Shifted slightly toward more enforcement | Local skill usage has been hard to track, or even skill in general, what triggers them or how they’re being used across different workflows. | ||||||||||||||||||||||
25 | We rely mostly on informal channels (Slack, office hours, etc.) | An expectation the Design System replaces design decisions. | Shifted slightly toward more enablement | Semantic naming conventions for components and props. | ||||||||||||||||||||||
26 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Shifted slightly toward more enablement | I would love to see visual coverage in customer facing products more along the lines of consistent experiences. e.g. in these similar experiences and user personas this is where we bring consistency. | ||||||||||||||||||||||
27 | It's used only by myself presently, so I have an omnipotent view. However, I still have build tracking and auditing tools into my MCPs to capture token and component usage. | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution | Shifted slightly toward more enablement | If I were working with a team of humans, I'd implement lead-level, cross-vertical design and prototype critiques/reviews. I find it's the optimal way to surface needs across teams to identify shared needs and challenges of those who are actually tasked with using the system. Crits are a more politically neutral space where opportunities for all forms of feedback — making enablement and enforcement equally possible. Creating a regular, dependable space for open possibilities better facilitates collaboration. | ||||||||||||||||||||||
28 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted significantly toward more enforcement | The most useful thing would be lightweight, embedded signal collection at the point of consumption rather than at the point of review. If contributors and consumers could flag uncertainty or deviation in context, without it feeling like a compliance checkpoint, you'd surface real usage patterns before they compound into systemic drift. The goal is making visibility a byproduct of normal workflow rather than a separate audit process that no one has time for. | ||||||||||||||||||||||
29 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Shifted slightly toward more enforcement | I would try to create a meaningful link between our DS analytics and our PM/ program tracking systems to create a correlation between System adoption and productivity | ||||||||||||||||||||||
30 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution | Shifted slightly toward more enforcement | Template usage | ||||||||||||||||||||||
31 | We have very little visibility, it's largely a black box | Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Shifted slightly toward more enablement | I would want visibility into any user testing folks do that provides them insight or direction. It would be great to see how they used the tools in the system, and how they adjusted, if at all, based on use and outcomes. We often think our tools are obvious, but there are so many ways that people can interpret how to use something, usually in ways we never even imagined. That would be even more powerful knowledge if they developed an experience with the system, and then revised their initial take based on user feedback. | ||||||||||||||||||||||
32 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Stayed about the same | I would love to be able to audit every product that uses our design system to better detect repeated patterns. Right now that visibility is very manual and doesn't cover every product. Having this insight would allow us to provide better component solutions, design patterns and AI context for our users. | ||||||||||||||||||||||
33 | Still building it. | Inconsistency accumulating faster than we can detect,The system being used incorrectly or out of context | Shifted significantly toward more enforcement | N/A | ||||||||||||||||||||||
34 | Launching a new DS and establishing these mechanisms. | This is a laundry list of things I hope AI and more robust design infrastructure will solve. Feels like the classic problems now have methods and tools available to build a more resilient DS. | Shifted significantly toward more enablement | Design System "sandbox" to give people enough access to the tooling while keeping it away from production pipelines. | ||||||||||||||||||||||
35 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution | Shifted significantly toward more enablement | permission to look into any related company or project files to gather our own use cases if nothing else | ||||||||||||||||||||||
36 | We rely mostly on informal channels (Slack, office hours, etc.) | Generating design.md files, skill files, plugins etc to support agentic workflows as much as possible | Shifted slightly toward more enforcement | Dashboards/visualizations with drill downs into how and where design system assets are being used — I'm not fully convinced this is any different than a human using these components but knowing how components/patterns are being used (via API/MCP, package import) would help direct planning and feature requests | ||||||||||||||||||||||
37 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | - Figma gives warning to users when they detach an instance from the system, and sends the system team a notification. (this is policing haha) - automatic codebase scan and matching agent to identify gaps between design and code. | ||||||||||||||||||||||
38 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | We haven’t gotten there yet - but do see the need for more checks /enforcement for AI generated designs, while still enabling human designers (and maybe even AI designs to some degree) to innovate and test. If it becomes so easy to generate new designs / code with AI, maybe it will also be easier/ less painful to ‘enforce’ changes that reach production but don’t align with the system or design language. | Better visibility of new designs in Figma - catching before it goes to code or gets approval on designs. Figma analytics aren’t super helpful except for aggregate usage, maybe some way to review files for handoff with flags for new patterns or questions for the design system team, and any new snowflakes clearly labeled with reasoning as to why they need something custom. | ||||||||||||||||||||||
39 | We have very little visibility, it's largely a black box | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | cross-channel analytics tool: giving an overview of code, vibe-coding, figma, etc. | ||||||||||||||||||||||
40 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enablement | Open source tracking of usage | ||||||||||||||||||||||
41 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Stayed about the same | Artifact usage metrics so we can confidently retire anything that isn't producing a high enough ROI to offset maintenance costs and so we can have real data to back up business cases. | ||||||||||||||||||||||
42 | We have robust, automated tracking and analytics | Inconsistency accumulating faster than we can detect | Shifted significantly toward more enablement | Keen to know! | ||||||||||||||||||||||
43 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution | Stayed about the same | I'd love to have tracking within the components so that I could review a weekly report breaking down which components are being used in which repos. Even more granular, if I could drill deeper into each component to learn which props are most commonly used or modified or customized, I'd be thrilled. | ||||||||||||||||||||||
44 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution | Shifted slightly toward more enablement | A Slack channel where anyone who's using system tokens or components can proactively inform us. Not automated, but a communicated request to drop a message in Slack to inform the system team you're using our stuff. | ||||||||||||||||||||||
45 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | A central gallery of vibe coded projects so we can see what folks are building and how we can direct the system to help. | ||||||||||||||||||||||
46 | We have very little visibility, it's largely a black box | Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Shifted slightly toward more enablement | I wish we had feedback on when consumers of our system needed to submit a follow up prompt because the output didn’t meet expectations on how system components or patterns are expected to be used | ||||||||||||||||||||||
47 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | Some sort of magic wand to see context or even a bit of background to why a component or element from the system was not used. Product teams run in to any number of issues and choices when it comes to solving customer problems, the system doesn't support 100% of that. Team have done work arounds sometimes because a component didn't exist yet (okay), some didn't have the time (less okay), and some didn't know or realize a similar component or pattern could be used (needs education). Being able to see / understand a bit deeper than a component wasn't used or a pattern wasn't followed and what may have been tried could support a more robust examples, guidance, and system education. If we're not recognizing system misuse or non-use as a signal to learn and support further, we're not creating or honoring our system principles. | ||||||||||||||||||||||
48 | We rely mostly on informal channels (Slack, office hours, etc.) | New patterns emerging that we can't see,The system being used incorrectly or out of context,Will people even care and just use whatever AI creates and not actually care about the quality and scalability of their products? (especially a11y) | We're fairly behind from where other companies are, so we're not as worried yet | I think for us, it’s less about “being used” and more about the fact that people are increasingly relying on my team to define how AI tooling should actually be implemented and used in design workflows. We’re becoming the team people turn to for questions like: How do we set up prototyping? How do we set up our dev environments? How should we use these tools more effectively? But we haven't been "assigned" or given that responsibility. It reminds me of Murphy Trueman’s blogpost, “The job nobody assigned,” especially the idea that design system teams are taking on AI-related responsibility before we've figured out where that work actually belongs. We’re not fully governing AI output yet, we’re filling a gap to help people get stood up so they can use the tooling at all. A lot of designers are understandably inexperienced with dev environment setup, working on branches, and dev tooling, etc. So we’re stepping in because we have more experience in this kind of thing to be helpful, but that also means we’re quietly becoming the enablement layer for AI-assisted design and prototyping without a clear mandate, resourcing, or decision-making authority. | ||||||||||||||||||||||
49 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,The system being used incorrectly or out of context | Stayed about the same | A manual checklist defined by frontend engineers and designers that show HITL was enforced. | ||||||||||||||||||||||
50 | We rely mostly on informal channels (Slack, office hours, etc.) | New patterns emerging that we can't see | Stayed about the same | I would love to see some type of automation to check on any variants of our component in the wild and the context of how they are used. Like is there an additional class name added or property that doesn't exist in our codebase that a developer might have added as a one-off | ||||||||||||||||||||||
51 | We have some manual processes or partial tooling | Losing the feedback loops that inform system evolution,The system being used incorrectly or out of context | Shifted significantly toward more enablement | Metrics tracking | ||||||||||||||||||||||
52 | We have very little visibility, it's largely a black box | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Shifted slightly toward more enforcement | build in design critique into the release process. I only just this week got access to an iPhone | ||||||||||||||||||||||
53 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enablement | Making the right thing easier. For us this involves improving our documentation so that we can continue to build the foundation to support AI using the system down the line. | ||||||||||||||||||||||
54 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Stayed about the same | Some sort of AI enabled scan of our enterprise GitHub universe of code repositories. | ||||||||||||||||||||||
55 | We have very little visibility, it's largely a black box | The system being used incorrectly or out of context | Stayed about the same | Not sure. | ||||||||||||||||||||||
56 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution | Stayed about the same | We definitely need a usage dashboard to see where components are being used. I'd also like to track things that look/feel like the components but are not using them. Partly to question why the components are not being used and to figure out where the components could be improved. I'm thinking a Claude Artifact with the ability to prompt it for more detailed insights would be really helpful. | ||||||||||||||||||||||
57 | We rely mostly on informal channels (Slack, office hours, etc.) | Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enablement | I simply want to be able to see how our components are being used in code so that we can identify gaps and/or stress points in the system. This includes things like prop usage, style overrides etc. | ||||||||||||||||||||||
58 | We have some manual processes or partial tooling | New patterns emerging that we can't see,The system being used incorrectly or out of context | Stayed about the same | A tool that can detect, document and propose emerging patterns (patterns across the atomic scale, from new atoms to components, compositions or higher level patterns). This would help us systemize at scale without policing. | ||||||||||||||||||||||
59 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see | Stayed about the same | Our products are fragmented across so many repos, it's incredibly difficult to get an accurate picture of where the system is being used and to what level. Having this information would be helpful to understanding where we can improve the system for greater adoption. | ||||||||||||||||||||||
60 | We have some manual processes or partial tooling | all of the above! we also have folks creating things faster than we can get them ideal context for our system, so we find they are "imitating" the system, not actually using the system. or using context from a moment in time, and not keep up w/ the system updates. | i feel like my feelings haven't changed. However, perspective of leadership seems to be changing quickly...hearing a lot more push on governance/enforcement as the future of our jobs, which makes me a bit...sad. | durp...i don't even know... i would love more automated synthesis of intakes/requests, to get a clear view of what people are asking for - this is so manual and no one has time to do this bigger picture view. we have some dashboarding, but its not consistent across our frameworks or design/tech. so, a singular holistic view would be awesome. it would be great to have a portal where you could view our products w/o being a customer/user of them - it is very hard to see our apps/sites in use...you're almost always looking at someone's figma mock ups, not the actual product. | ||||||||||||||||||||||
61 | We have some manual processes or partial tooling | New patterns emerging that we can't see | Shifted significantly toward more enablement | Component-level metrics. We have a pretty good idea of what’s used most often based on our support channels, but it would be nice to have some actual numbers to prove/challenge our assumptions. | ||||||||||||||||||||||
62 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | I wish I could have a library of live in production links to various tools and products that use the design system to see how folks are utilizing it. It is nearly impossible to track how the system is used and what is experimental vs what actually is live in our apps. I think a live library could be a great way to see everything as one picture, see how internal tools handle problems vs external. What servicing does vs marketing. Could be a great asset for AI to then analyze and perhaps call from to help other folks solve similar problems (as long as the live products are actually using the system correctly) | ||||||||||||||||||||||
63 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,The system being used incorrectly or out of context,Trying to build accessible components is one thing our team has spent a lot of time on, something that AI prototypes sometimes overlook. | I would love more analytics and/or clearer real-world examples that would help inform how we build components. | |||||||||||||||||||||||
64 | Unsure. I believe the team has some processes, but more likely informal channels. | The system being used incorrectly or out of context | Shifted slightly toward more enablement | Detect % of adoption across a product or service so stakeholders would understand the scope of work remaining to achieve ideal consistency and in nearly all cases better accessibility. | ||||||||||||||||||||||
65 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see | Shifted significantly toward more enablement | Visibility in a marketplace where everything is out in the open. | ||||||||||||||||||||||
66 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context | Our DS is currently in pre-launch, so it's a bit too early in our evolution for me to have a good answer right now. We're aware of this looming issue though, we just haven't had time to put a lot of brain cells onto it yet. Our lead (Taylor) might answer this differently--it's possible he's thought/thinking about it more than we know, but wants to keep the team focused right now on getting v1 launched. | A comprehensive metrics dashboard (including an AI agent to sift through data, look for trends, etc.) that accommodates our use of the Web Components framework. A 3rd party tool like Omlet is too limited for our DS--it only accommodates React, but we need more than that for tracking: React, Next.js, bundler-based and script-based JS, and more frameworks to come in the future as we are able. We have a huge org, and no one framework reigns supreme currently. | ||||||||||||||||||||||
67 | We have some manual processes or partial tooling | Losing the feedback loops that inform system evolution,The system being used incorrectly or out of context | Shifted significantly toward more enablement | We would like clearer visibility on how and when it our DS data is being used within AI systems. Not sure how this could be monitored well, without infringing on our colleagues privacy by saving AI chat logs or somethings similar. But given our positioning right now it would massively help us, help the teams utilising AI tooling better with the DS. | ||||||||||||||||||||||
68 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enablement | Standard processes across teams and clear foundational expectations about usage of the system, i.e. “I don’t have time to use that, it’s faster for me to create/do my own thing” is a non-starter. | ||||||||||||||||||||||
69 | It's complicated. | Inconsistency accumulating faster than we can detect,New patterns emerging that we can't see,The system being used incorrectly or out of context,Making sure that guidance is out there as quickly and accurately as possible and then that people will follow/use it. | I almost answered "stayed the same", but it's sort of both on either side of that ("shifted slightly toward more enforcement" and "shifted slightly toward more enablement"). | I recently shipped a docsite that my coworkers were over the moon about. Personally, I see documentation as the gateway to AI. It becomes the context that creates guardrails for an agent and what it can and can't do. | ||||||||||||||||||||||
70 | We have some manual processes or partial tooling | We have the same problems we always have, just magnified by the scale of AI. Our current biggest challenge is providing a solution for design system context to these agents, in a way that is managed and distributed, rather than various "copies" of context floating around the org. Once people get their hands on system context, the next challenge will be layering on the additional context needed to operate agents within a product scope. We don't have enough structure around this context ecosystem for agents to operate effectively. Humans can manage this ambiguity, but agents cannot. Our system has many gaps including low component availability on certain platforms, as well as an immature extension/local system model. With low coverage at the local level, we'll quickly expose how disorganized we are when it comes to composing design system pieces in the context of products. | Shifted slightly toward more enablement | Tracking adoption of our forthcoming design system AI tooling. This will be a huge enabler and self-enforcer for teams. Governance will live in the process, instead of being an end-stage gate. Our confidence is proper system use will greatly improve. | ||||||||||||||||||||||
71 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect | Shifted significantly toward more enablement | Move more enablement to the foundational layers of the system—tokens, surface primitives, layout primitives, etc. Instead of trying to beat agents on generating new UI patterns (a losing battle, agents will always be faster), lets make sure the agnostic starting points are supported so that anything that’s generated through agentic workflows uses the system as a starting point. | ||||||||||||||||||||||
72 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | If I could instantly implement one thing, it would be a lightweight design system health dashboard. I’d want visibility into component adoption, duplicated patterns, accessibility gaps, and where teams are working outside the system, including how AI-generated code or AI-assisted workflows are influencing implementation quality and consistency. The goal wouldn’t be to become the “design police,” but to better understand where friction exists and how teams are actually building to better evolve the system to support their needs. | ||||||||||||||||||||||
73 | I'm a one-person operation. I make the design system and production code. I've automated tools to produce a table showing me which components, styles, and tokens are in use and how often. Prior to now, during my time at other companies, I had enthusiastic partnership but zero visibility. | The system being used incorrectly or out of context | Stayed about the same | I would include a "purpose" or "description" member in the JSON of every token and style to note what the intended purpose of each. Then I would use AI to run weekly checks of production to determine: • Usage: which styles and tokens are in use and where, • Alignment: which styles and tokens are used in alignment with their intended purpose. • Misalignment: which styles and tokens are in use but not for their intended purpose. • Missed opportunities: which code instances could be served by an existing style or token but are not. | ||||||||||||||||||||||
74 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | I'd love an easier way to understand the intent of behind deviations. Our team has automated processes for detecting overrides but we don't know *why* they're happening unless we stop and have a conversation, and overrides happen at a much faster rate than we can reasonably stop to talk about. We want to know why a designer chose to deviate from the system so we can understand if the system needs to be updated. | ||||||||||||||||||||||
75 | We have very little visibility, it's largely a black box | Losing the feedback loops that inform system evolution,The system being used incorrectly or out of context,That AI becomes the DS' primary user. | Shifted significantly toward more enablement | Metrics: Usage, Component Adoption Rate. Contribution Rate, NPS. There's nothing right now :( | ||||||||||||||||||||||
76 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context,Product teams leaning on the design system AI tooling to be a replacement for working with humans to be involved in the UX work. | It seems like the rules we’re incorporating into our design system are helping enforce the system, while simultaneously making these AI Skills available is actually aiding in the enablement of AI. Consequently, we’re doing both, and we’re currently prioritizing this work over everything else to stay ahead of the ongoing debt accumulation caused by product teams leveraging AI development with their own versions of AI-generated design system guidance. | Our system is utilized by numerous internal and external company products. Currently, the documentation and examples for our patterns and components lack a strong opinionated approach to system usage, which we aim to enhance. Implementing automation to crawl various products and identify usage examples would be beneficial for analysis and representation in the documentation. | ||||||||||||||||||||||
77 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect | Shifted slightly toward more enforcement | Not sure right now | ||||||||||||||||||||||
78 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted significantly toward more enforcement | Since so much of our jobs has become AI agent governance, I want robust evals yesterday so I can _actually_ get a pulse on the quality of what's going out right now. | ||||||||||||||||||||||
79 | We have some manual processes or partial tooling | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enablement | Better reporting I guess. | ||||||||||||||||||||||
80 | We rely mostly on informal channels (Slack, office hours, etc.) | Inconsistency accumulating faster than we can detect,Losing the feedback loops that inform system evolution,New patterns emerging that we can't see,The system being used incorrectly or out of context | Shifted slightly toward more enforcement | Better scanning tools to understand implementation patterns in existing applications vs spec driven / vibe code driven development with AI tooling. While AI can pick up on some of the larger patterns, it's good to be able to scan the usages and help to build better documentation / context / rules / tools to drive consistency across AI. | ||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||