💬 EN

Where do the speakers seem to display emphasis or passion, as if they’re stumbling onto a game-changing point that might feel monumental to listeners?

Based on the provided sources, the speakers, Elise Holiday and Ben Callahan, display notable emphasis and passion on several key points throughout their conversation, often highlighting challenges or offering insights that seem particularly impactful to them and potentially to their listeners.

Here are some areas where their emphasis and passion are evident:

• The Struggle of Organizations to Support Design System Teams: Ben repeatedly emphasizes that organizations often “don’t know how to support these teams”. He connects this to the difficulty in asking product designers to “go sell the concept” of how they work to the rest of the organization, highlighting that this strategic responsibility usually falls to leadership. Elise echoes this sentiment, noting that companies “don’t quite know how to take care of these teams yet”, despite their expanding responsibilities.
• The Insight of “Wanting a Design System but Not a Team”: Ben shares a customer quote that has “stuck in [his] head all week”: “I think we want to have a design system but we don’t want to have a design system team”. He reacts with surprise (“wait really like think about that”), underscoring this as a profound observation about the gap between desiring the benefits of a system (efficiencies, accessibility, consistency) and facing the reality of requiring organizational change and dedicated resources.
• Design System Work as Organizational Behavior Change: Elise strongly posits that design system work is “organizational behavior change”, describing it as “muddy and sticky and messy and hard”. Ben agrees, noting he is “fascinated with that part of the work” and believes the tactical implementation has been codified over the last decade, while the “hard work, which is like actually getting the org to want to use it”, remains the primary challenge.
• The Age-Old Problem of Designer and Developer Collaboration: Ben points out that the difficulty in getting designers and developers to work well together is “the problem before systems ever existed”, labeling it “the age-old problem”. He reacts with strong emphasis (“Oh my gosh, that’s like the problem”), suggesting this enduring challenge is fundamental, even beyond the technical aspects of design systems.
• The Importance and Neglect of “Front of the Front-End” Work: Ben argues that the removal of dedicated “front of the front-end” roles has been “really detrimental”, stating that “nobody acknowledges the importance of this layer of work” which sits between design and development. Elise responds with clear passion, declaring, “Well, I’m here for the return of professional CSS person as a job”, highlighting her personal connection to this type of work and her hope for its resurgence. Ben reinforces this by noting that “most engineers… just don’t want to do that work”.
• The Critical Need to Show/Prove Impact: Elise identifies showing or proving what a design system is “actually doing for an organization” as “the most pressing question in design system land right now”, particularly in the context of recent layoffs where teams were heavily impacted. She passionately asks how they can align design systems with what the business “is actually in need of and really really valuing”.
• The Myth of 100% Component Coverage: Ben describes an insight from “The Question” where a respondent noted diminishing returns on adding more components because their coverage was already good. This idea “just really got me thinking”, leading him to conclude that the concept of “100% the system needs to do everything is just like such a myth”. This reframes a common goal as potentially counterproductive.
• The Value of Education and Engagement Alongside Evolution: Ben emphasizes the pattern seen in the “most successful” organizations where work is split into three “E’s”: evolution, education, and engagement. He expresses a strong desire (“I would love to see 33% on all those”) to shift focus from the common practice of spending 98% of time on evolution to more balanced effort across all three, arguing that engagement can make the system “something they can’t do their jobs without” and thus “gets rid of adoption as a concern”.
• Pushing Back on “Adoption Doesn’t Matter”: Ben directly challenges the idea that adoption doesn’t matter, stating forcefully, “I’m tired of people saying adoption doesn’t matter I just want to say that”. He argues that if the system embodies best practices, adopting those practices is valuable. Elise clarifies that it’s the definition of adoption (e.g., a meaningless, gameable number) that can be nonsense, not usage itself.
• The Quadrants of Impact: Elise is visibly enthusiastic about Ben’s diagram explaining the different quadrants of design system impact, calling it “one of the coolest things” and praising his “excellent job”. This visual representation provides a framework for understanding different approaches (strategic vs. tactical, common vs. unique patterns) and their outcomes (efficient cohesion, futureproof, adding components, inefficient cohesion). Ben specifically highlights the “add more components” quadrant (bottom right) as “one of the most dangerous places” for design systems.
• The “Spicy Take” on Consistency: Invited for a “spicy take”, Ben delivers a passionate assertion: “I don’t think your design system is going to make your products more consistent”. He argues forcefully that consistency “comes from culture and that comes from the cohesion that strategic work at the top of that diagram”, labeling the idea that systems automatically bring consistency a “misnomer”.
• The Nature of Design System Work as “Glue Work”: Elise brings up Tanya Riley’s concept of “glue work”, defining it as the essential coordination and communication that makes things happen. She states with conviction, “I think 90% of design systems work is glue work. The components are easy”. This reframes the primary activity of design system teams as something often devalued in traditional career paths.
• Debate on Team Size and Scope: Elise passionately disagrees with Ben’s prediction of constricting scope. She argues that small teams can be more focused and nimble, leading to better relationships and direct engagement with product teams. Her prediction is that “scope is going to get bigger and teams are going to get smaller. And I I want to see it work”, displaying a clear, hopeful vision for the future model of design system teams.

These moments, characterized by strong language, personal reflections, and challenging conventional wisdom, appear to be where the speakers feel they are uncovering or reinforcing crucial insights about the challenges and potential of design systems work.

I keep wanting to send this episode to “product team” developers and their managers, but I can’t put my finger on why I feel so passionately that I want to send it to them, rather than to “design system team” designers. What’re the “See?! You’ve got to __” moments that product development teams might benefit from me shoving down their throats?

Okay, I can definitely see why you feel passionately about sending this episode to product team developers and their managers. The conversation between Elise Holiday and Ben Callahan touches on several fundamental challenges and insights that directly impact and involve product development teams, often from a perspective that system teams grapple with daily but that product teams might not fully appreciate or understand.

Here are some of the “See?! You’ve got to __” moments from the sources that product development teams (developers and their managers) might particularly benefit from hearing, framed through the lens of what they “have to” understand or do:

• See?! You’ve got to understand that design system work is fundamentally about changing how you work, not just providing assets.
  • Ben notes that while the theoretical potential of a system (efficiencies, accessibility, consistency) is an easy pitch, the reality is that you’re asking “every single team that is working on product inside of an organization” to “change how they work”. Elise agrees, strongly stating that design system work is “organizational behavior change,” describing it as “muddy and sticky and messy and hard”. This is a core insight that shifts the focus from the system as a passive library to an active force requiring adaptation from consuming teams.
• See?! Your managers have got to understand that supporting the design system team and driving organizational change is their job, not the system team’s job.
  • Ben points out that asking product designers to “go sell the concept” of how they work to the rest of the organization isn’t standard practice. Strategic responsibility for having “hard conversations,” figuring out budget, and prioritizing work falls to “a whole hierarchy of leadership”. Both speakers emphasize that “organizations don’t know how to support these teams”. This is a direct call-out to leadership – the product managers – that they are crucial to the system’s success.
• See?! You’ve got to realize that the system team isn’t there to build everything for you, especially unique, product-specific components.
  • Ben highlights an insight from “The Question” where a team realized that adding more components had “diminishing returns” because their core coverage was already good. The idea that “100% the system needs to do everything is just like such a myth” is reinforced. Ben’s quadrants diagram labels the bottom-right quadrant, “Add More Components” (Tactical + Unique Patterns), as “one of the most dangerous places” for design systems. Elise adds that trying to put product-specific components (like a unique app bar) into the shared system is inappropriate and “doesn’t even belong in here”. For product teams constantly requesting specific components, this explains why the system team might resist or why it’s not the system’s core purpose.
• See?! Developers, you’ve got to acknowledge the crucial “front of the front-end” gap, and managers, you’ve got to value and support this role.
  • Ben argues that removing the dedicated “front of the front-end” role has been “really detrimental”. He states that “nobody acknowledges the importance of this layer of work” that sits between design and development. He points out that “most engineers… just don’t want to do that work”. This directly addresses a common pain point in handoff and implementation that product teams face and explains why it’s difficult to bridge. Elise passionately calls for “the return of professional CSS person as a job”, validating the importance of this layer.
• See?! Managers, you’ve got to understand that the design system’s value needs to align with what the business is actually prioritizing, not just theoretical benefits.
  • Elise identifies proving what the system is “actually doing for an organization” as the “most pressing question”. She connects this to the fact that design system teams were heavily impacted by layoffs because organizations didn’t see them as “the most important thing to keep”. Ben discusses the danger of making promises about efficiency or cohesion based on individual executive priorities rather than getting leadership together to “put our priorities in order”. He notes that systems are a tool to latch onto “on fire” business reasons like rebrands or acquisitions. This helps managers see the system not as an abstract good, but as a tool to solve concrete, existing business problems they care about.
• See?! You’ve got to recognize that consistency comes from culture and strategic alignment, not automatically from using system components.
  • Ben offers a “spicy take”: “I don’t think your design system is going to make your products more consistent”. He argues forcefully that consistency “comes from culture and that comes from the cohesion that strategic work”. Elise and Ben agree that you can build “absolute nonsense” or “really terrible things with any design system”. This challenges a fundamental assumption product teams might have and places the responsibility for consistency back on their cultural practices and adherence to strategic goals.
• See?! You’ve got to appreciate that much of the system team’s valuable work is “glue work” – coordination and communication – which enables you to ship, but isn’t just building components.
  • Elise emphasizes Tanya Riley’s concept of “glue work,” describing it as the essential coordination, communication, and “herding cats” that makes things happen. She states with conviction, “I think 90% of design systems work is glue work. The components are easy”. Product teams might only see the component building, but this points to the unseen effort that facilitates collaboration and consistency across the organization, directly benefiting how product teams work together and integrate their efforts.
• See?! You’ve got to benefit from system teams shifting focus to Education and Engagement, not just building.
  • Ben highlights that successful organizations balance system work across Evolution (building), Education (training), and Engagement (working with teams to understand needs). He notes that most teams spend 98% on Evolution, while engagement can make the system “something they can’t do their jobs without,” getting rid of adoption concerns. Elise describes a specific example of a developer changing their behavior (using CSS grid patterns) after working with her, calling it “behavior change” that’s hard to number but is real impact. This shows product teams that the system team’s potential value lies significantly in helping them learn and apply best practices, not just providing tools.
• See?! You’ve got to understand that adoption (using the system/its patterns) does matter if you want the benefits, though the metric can be messy.
  • Ben pushes back on the idea that “adoption doesn’t matter,” stating forcefully, “I’m tired of people saying adoption doesn’t matter”. He argues that if the system embodies best practices, adopting those practices is valuable. While Elise clarifies that how adoption is measured can be nonsense, the actual “usage” and following of patterns is important. This is relevant for product teams who might dismiss calls for adoption, explaining that meaningful usage directly leads to the desired outcomes like consistency and efficiency.

These points directly address the pain points, assumptions, and incentives common within product development teams and their leadership. They provide a framework for understanding the challenges the system team faces, the real value a system can provide beyond just components, and what organizational/behavioral shifts are necessary for success, making the episode potentially very impactful for that audience.

I think I want to reassure developers that they’ve got design system professionals in their corner when they feel overwhelmed wondering if there’s some sort of organizational mandate to make all of their product UIs robotically conformant to whatever UI elements happen to have made their way into the enterprise’s centralized design system.

That’s a really insightful goal – you want product developers to feel seen and understood by the design system professionals, and to alleviate the pressure of feeling like they must conform rigidly to a potentially incomplete or ill-fitting centralized system. The sources provide excellent material to support this message.

Here are some points from the sources that can help reassure developers that the design system team is not just focused on robotic conformance but understands their challenges and unique product needs:

• The design system team understands that building product UIs is messy and hard, involving deep challenges beyond just components. The speakers discuss how getting designers and developers to work well together is an “age-old problem” that existed long before design systems. They acknowledge that design system work involves navigating the “waste deep mud of like people’s baggage” and is fundamentally “organizational behavior change” that is “muddy and sticky and messy and hard”, even in organizations that want the change. This shows the system team is aware that implementing a system into a product team’s workflow isn’t a clean, simple process.
• You are not expected to build everything with the centralized system’s components. The idea that “100% the system needs to do everything is just like such a myth”. Ben’s quadrant diagram highlights that constantly adding more and more unique, product-specific components to the system (the “Add More Components” quadrant) is “one of the most dangerous places” for design systems. Elise reinforces this by saying unique product elements, like a specific app bar, “doesn’t even belong in here”. This directly counters the fear that every single UI element must come from or strictly adhere to the central system.
• The system team recognizes and values the critical role of “front of the front-end” work. Both speakers lament the loss of dedicated front-of-the-front-end roles, acknowledging that this is the layer building “the thing the users touch” and requires specific skills. They admit that “most engineers… just don’t want to do that work” and that removing this role has been “really detrimental” to designer-developer collaboration. This shows an understanding of the specific development challenges developers face when building UI and validates the importance of that often-difficult layer.
• Consistency is a product of culture and strategy, not just using system components. Ben offers the “spicy take” that the design system is unlikely to inherently make products more consistent because “you can build really terrible things with any design system”. True consistency “comes from culture and that comes from the cohesion that strategic work”. This reassures developers that the system components are merely a tool, a “method, a modality by which we share that information”, and that the responsibility (and difficulty) of achieving consistency lies in broader organizational practices and values.
• The design system team’s valuable work includes supporting and educating product teams, not just building assets. Ben identifies “Education and Engagement” as critical buckets of system work, alongside Evolution (building). Engagement means the system team wants to “dig in with these teams and understand what’s actually happening in their worlds” to make the system something they “can’t do their jobs without”. Elise shares a tangible example of helping a product developer adopt new CSS grid patterns through collaboration, calling it real “behavior change” that is valuable impact. This shows developers that the system team sees itself as a partner in helping them build better UIs, not just a provider of rigid assets.
• The system team understands that different products have different needs. Elise gives the example of building a consumer product and an internal tool, noting they have “very different needs, very different users, different design principles”. This implies that the system team recognizes that a single, rigid set of components might not be appropriate or even possible for all products.
• Much of the system team’s work is “glue work” – the essential coordination and communication that helps all teams ship. Elise emphasizes that “90% of design systems work is glue work. The components are easy”. This highlights the unseen effort the system team puts into making collaboration and shared understanding possible across the organization, which directly benefits product teams by reducing friction and enabling them to ship.
• The system team faces its own challenges, including lack of support and resources from the organization. The speakers repeatedly mention that “organizations don’t know how to support these teams” and that design system teams were heavily impacted by layoffs because their value wasn’t always understood by leadership. This can foster empathy from product teams by showing that the system team is also navigating organizational hurdles and isn’t necessarily a fully empowered entity dictating terms.
• There’s a “healthy tension” between system and product concerns. Ben concludes that there is a “really healthy tension between the system designer concerns and the product designer concerns” and that having people advocate for both perspectives is crucial. This frames the relationship not as adversarial, but as a necessary balance needed to build successful products and a successful system.

These points collectively paint a picture of design system professionals who are grappling with the same complex organizational and technical realities as product developers. They are not simply component purists demanding conformity, but individuals trying to drive broader, messier change, acknowledging product-specific needs, valuing development craft, and often feeling unsupported themselves. Sending this episode can indeed help developers see that the design system team is in their corner, understanding many of their frustrations and working towards goals that, when properly aligned, benefit the product teams directly.

I think I’d also like to convince developers that, despite that, they shouldn’t just be waiting around for the design system to be “complete” and perfectly fit their needs before even poking around at “using” it in their products. That they should treat it like when they do an “npm import” or “dotnet install” or “Install-Module” of some sort of useful open-source thing that maybe only has one useful feature and is just clutter otherwise, and that also they can contribute pull requests back to. But I’m not sure how to sell the “what’s in it for them, the product developers” and motivate them to think this way. (After all, “what’s in it for them” about waiting around for the design system to be perfect is “I get to do less work, by pretending there’s nothing I could be helpful with anyway.” A sort of weaponized incompetence to preserve work-life balance and avoid scope creep when under-resourced already.)

That’s a fantastic goal. You want to encourage product developers to see the design system not as a rigid, mandated set of rules or an excuse to wait for perfection, but as a living, breathing resource they can leverage now and help shape. You’re spot on that understanding “what’s in it for them” is key to motivating this kind of engagement, especially when teams feel under-resourced.

Drawing from the sources and our conversation, here’s how you can frame this message to developers:

1. Acknowledge the Myth of the “Complete” System:
   • First, validate their feeling that the system might not contain everything they need yet. The sources reinforce that the idea of “100% the system needs to do everything is just like such a myth”. It’s not designed to cover every single unique UI element or use case from day one, or perhaps ever.
   • Ben’s quadrant diagram points out that constantly adding more and more product-specific components (the “Add More Components” quadrant) is “one of the most dangerous places” for design systems. Elise gives a concrete example of an app bar that “doesn’t even belong in here” in their shared system because their products have very different needs. This perspective from the system side shows they understand not everything fits or should be in the central system.
2. Embrace the “Use Parts, Contribute Back” Model:
   • Lean into your analogy of treating it like an open-source library you’d npm install. The system provides the “fundamental low-level assets for teams”, like “Lego bricks”.
   • The sources directly use this analogy when criticizing teams that build fundamental components like buttons and inputs from scratch, noting you could “literally npm install” something and theme it. This reinforces that leveraging existing assets, rather than rebuilding or waiting for a perfect system to magically appear, is often the more efficient path. The system offers tactical assets that are ready to be pulled in.
3. Highlight “What’s In It For Them”: This is the crucial part for overcoming the inertia of waiting.
   • Ship Faster, Meet Deadlines: Using components or patterns from the system, even if incomplete, can offer immediate speed benefits. It’s a tool to “get this stuff done right now”. For example, using system components for common patterns like navigation or modals helped a team meet a “really incredibly tight turnaround deadline” despite different product needs. The system can be a tool to tackle urgent business needs like integrating products after an acquisition.
   • Get Support and Education: The design system team isn’t just building assets; they aim to spend significant time on “Education and Engagement”. They want to “dig in with these teams and understand what’s actually happening in their worlds”. By engaging, developers open the door to this support. Elise gives an anecdote of helping a developer adopt CSS Grid patterns, calling it real “behavior change” that resulted from collaboration – a direct benefit to the developer’s craft and code quality.
   • Improve Code Quality and Learn Best Practices: The system embodies desired practices. Using it, even partially, means following those established patterns. Engaging with the system team or contributing can help developers learn newer, better ways of building UI.
   • Have a Voice and Influence the System: The system team needs input from product teams. Contributing feedback or code helps ensure the system evolves to actually meet product needs and reduces the “friction” that happens when the system is misaligned. Developers who engage help shape the system into something “they can’t do their jobs without”. There’s a “healthy tension between the system designer concerns and the product designer concerns”, and developers advocating for their needs is crucial.
   • Validate Their UI Craft: The system team understands and values the complex “front of the front-end” work that developers do – building “the thing the users touch”. They acknowledge that this is difficult work that many engineers don’t want to do and that losing this focus has been “really detrimental”. Engaging with the system, which is deeply tied to this layer, can help elevate the importance of this craft within the organization.
4. Address the “Less Work” Mindset & Resource Constraints:
   • Acknowledge that building product UIs is “messy and hard”, organizational change is “muddy and sticky and messy and hard”, and teams often feel stuck due to factors like tech debt, opinions, and lack of clear direction. The sources also point out that system teams themselves often feel unsupported and undervalued, highlighting that resource constraints are a systemic issue impacting everyone.
   • While the sources don’t directly address “weaponized incompetence,” the implicit counter to the “I get to do less work by waiting” mindset is that waiting might actually lead to more work or slower progress in the long run. Rebuilding common patterns from scratch or manually maintaining inconsistencies is ultimately less efficient than leveraging existing assets or contributing to a shared resource that improves over time. Engaging proactively is an investment that pays off in speed and reduced rework later.

In summary, you can reassure developers by showing them that the design system team understands their challenges, doesn’t expect robotic conformity to an incomplete system, and actively seeks to partner with them. The system is a tool that can help them solve their immediate problems – shipping faster, getting support, improving code, and having a voice – if they engage with it proactively, even when it’s not “perfect.” This frames engagement not as extra work for the system team’s benefit, but as leveraging and shaping a resource that offers tangible benefits to their daily work and product goals.

How could product developers potentially contribute at an organizational culture & strategy messaging level, celebrating the ways they’re “using” the design system, when all they’re actually doing for literal UI component HTML/CSS/etc. is “npm install”-ing some 3rd-party component library, for the most part? Like, how can they make it sound like they’re bought into “using” it when, at first blush, they’d probably presume they’re “not using it” because they’re not using its tactical low-level components at all?

Okay, consider this an “Annual Design System Impact Report” from the perspective of a product development team that relies heavily on a third-party component library for core UI elements, framed to celebrate their adherence to and support of the organizational design system’s goals and principles.

---

Product Team X: Annual Design System Impact Report - FY 2025

This past fiscal year, Product Team X successfully leveraged the organizational Design System’s strategic guidance and foundational assets to rapidly deliver high-quality, cohesive user interfaces, even while utilizing an npm-installable third-party component library for core HTML/CSS components. Our contributions demonstrate a deep buy-in to the system’s principles, showcasing how teams can achieve significant impact and alignment through diverse implementation strategies.

Here are the key ways Product Team X actively “used” and contributed to the Design System’s success:

• Embodied Strategic Values & Achieved Cohesion: We centered our development process around the Design System’s strategic principles and organizational values for visual consistency and user experience. By prioritizing alignment with these core tenets, our implemented UI feels like a unified part of the larger product family, successfully achieving the goal of “efficient cohesion”, proving that consistency stems from shared culture and values, not solely from using the system’s specific component code.
• Consumed Foundational Assets & Patterns: We directly integrated and applied the Design System’s “fundamental low-level assets for teams”. This included rigorous application of the system’s established design tokens (colors, typography, spacing, etc.) to theme and style the third-party component library. Furthermore, we actively followed the interaction patterns and layout guidelines documented within the system, ensuring that even components from an external source were assembled and behaved according to internal best practices.
• Accelerated Development Through Efficient Tactical Integration: By selecting and integrating a robust, npm install-able third-party library themed with system tokens, we significantly accelerated our development cycles. This approach maximized efficiency in building common UI patterns, allowing us to operate in “speed mode” and rapidly deliver features aligned with organizational needs, freeing up the central Design System team to focus on more complex or strategic challenges.
• Actively Engaged and Provided Valuable Feedback: We contributed to the Design System’s crucial “engagement” pillar by providing practical, real-world feedback on how system tokens and guidelines integrate with external component libraries. This feedback loop is vital for the system team to understand and document diverse implementation scenarios, helping to make the system’s documentation and guidance more robust and valuable for all product teams.
• Supported System Scope and Focus: By effectively addressing our common UI needs using a themable third-party library, we avoided the common pitfall of requesting the central Design System team to build or maintain product-specific components. This strategic choice respects the system’s intended scope and allows the core team to focus on truly common elements or strategic, “future-proof and far-reaching” initiatives, rather than becoming a repository for components with “diminishing returns”.
• Leveraged the System as a Strategic Tool: We viewed and utilized the Design System not merely as a component library, but as a powerful “tool” to achieve business outcomes. By aligning our workflow and technical choices with the system’s underlying principles and foundational assets, we demonstrated how the system enables teams to navigate challenges like tight deadlines or feature development, regardless of the specific component source, ultimately driving desired organizational results.

Product Team X’s approach exemplifies how “adoption” of a design system is about more than just code provenance; it’s about aligning with patterns, principles, foundational assets, and engaging with the system team to build products that serve organizational goals effectively and efficiently.

Amazing! Can I see it shorter – just one sentence or maybe two short ones per point?

Okay, here is a shorter version of the “Annual Design System Impact Report” from the perspective of a product development team, condensed to one or two short sentences per point:

---

Product Team X: Annual Design System Impact Report - FY 2025 (Condensed)

Product Team X effectively utilized the organizational Design System’s strategic guidance and foundational assets this past year, contributing to cohesion and efficiency despite using a third-party component library for core UI.

• We prioritized strategic alignment with the system’s values, ensuring our UI felt like a unified product family regardless of component origin. This focus on shared culture achieved “efficient cohesion”.
• We directly consumed foundational assets, rigorously applying the system’s design tokens for colors, typography, and spacing to theme our third-party components. We also followed system-defined interaction patterns and layout guidelines.
• Leveraging a themable third-party library allowed us to accelerate development cycles significantly. By styling with system tokens, we operated in “speed mode” to deliver features quickly and efficiently.
• We actively engaged with the system team, sharing real-world feedback on integrating external libraries with system tokens and documentation. This contribution helps refine the system’s guidance for all teams.
• By effectively using a themable third-party library for common needs, we supported the system’s intended scope and avoided asking the core team to build product-specific components.
• We used the Design System as a strategic tool to achieve business outcomes, demonstrating how its principles and assets enable rapid feature delivery regardless of component source.

Can you make me a humorous “bingo card” of “wins” that product development teams can bullshit to brag about “using” the design system? Keep them to just a handful of words – they need to fit on a bingo card! I like the idea of product teams trying to “adopt” the design system by playing a game without actually having to do hard work that doesn’t make sense for their product and without having to worry that they’re scope-creeping ahead of organizational mandates.

Alright, let’s lean into that glorious paradox: claiming credit for robust design system “adoption” when your component layer is essentially off-the-shelf. It’s all about reframing “usage” through the strategic and foundational lenses the sources highlight, even if the tactical code is coming from elsewhere. Think of it as playing the design system game on hard mode, where your wins are less about installing our button and more about installing our mindset (and maybe a token or two).

Here’s your humorous “Design System Bingo: Product Team Edition” list of brag-worthy “wins”:

• Applied System Tokens - You used the right color codes! Gold star!
• Followed System Layouts - The spacing looks mostly correct!
• Aligned w/ Core Principles - We thought about consistency.
• Attended System Session - Sat through an hour-long meeting! Engagement!
• Provided Token Feedback - Sent a Slack message asking about hex values.
• Didn’t Ask for Component - Successfully found it in the 3rd-party library instead.
• Themed a 3rd-Party - Proof the tokens can be applied to something.
• Mentioned “Cohesion” - Used the magic word in a stand-up.
• Talked “Speed Mode” - Justified rapid development using system buzzwords.
• Avoided Component Trap - Consciously decided not to ask for that hyper-specific thing.
• Installed System Package - It’s in the package.json! That counts, right?
• Read System Docs - Skimmed the README for five minutes.
• Cited “Org Change” - Sounded strategically insightful in a discussion.
• Discussed “Impact” - Nodded sagely when someone else said “impact.”
• Used System Naming [implied by tokens/patterns] - Used the official name for ‘Primary Button’ (even if it was the 3rd-party one).
• Briefly Paired w/ DS Team - Caught them in the hallway for a quick question.
• Referenced System (Anywhere) [implied by patterns] - Pointed to any system artifact during a review.
• Said “It Depends” - Showed nuanced understanding of system constraints.
• Added More Tokens [55, implies refactoring] - Made a PR that updated token usage in existing code.
• Trained Colleague on Tokens - Told someone else where to find the color codes.
• Avoided Product-Specific Comp - Didn’t burden the system with our unique snowflake.
• Used a Component (Properly) [implied by patterns] - Used that 3rd-party modal exactly as the system patterns suggest.
• Leveraged System for X (X=Project) - Tangentially tied system principles to project success.
• Adopted DS Accessibility [implied] - Followed the system’s WCAG guidance (even if it was generic).
• FREE SPACE: Shipped a Feature - Because ultimately, that’s what product teams do, system “usage” or not!

These bullet points represent the squares on your hypothetical bingo card. They capture the spirit of teams navigating the system’s expectations by finding ways to connect their work back to its broader goals (like cohesion, efficiency, or shared understanding), even when their literal UI components come from an npm install. It’s about celebrating adherence to the system’s strategy and foundations, not just its specific tactical code library.

Okay, now let’s level up the effort a scootch. How about a “make the Design System team members faint with surprise and delight” Bingo card for product developers to try to “win”? :) Again, please keep it short and sweet – it goes on a Bingo card.

Alright, let’s craft a “Make the Design System Team Faint (With Delight!)” Bingo card! These are the actions from product teams that show genuine understanding, effort, and partnership, drawing on what the sources suggest are challenging or valued aspects of design system work.

Here are some “wins” designed to truly surprise and delight the Design System team, short and sweet for your Bingo card:

• Reported a Real Bug: Found and documented an actual issue in a system component or doc.
• Contributed a Fix: Went the extra mile and submitted a pull request to fix something in the system.
• Asked “Why?” About a Pattern: Engaged with the reasoning behind a system pattern, not just its existence.
• Proposed a System Improvement: Shared a thoughtful idea for how the system could be better, based on real use.
• Themed a Complex Pattern: Successfully applied system tokens and patterns to a non-trivial product UI element or flow.
• Showed Genuine Excitement: Expressed sincere enthusiasm for a system release or feature.
• Volunteered for User Testing: Offered time to provide feedback on system changes or documentation.
• Defended System Principles: Advocated for using system approaches or patterns in a product team discussion.
• Didn’t Build a One-Off Comp: Used the third-party library or existing system parts instead of creating a net-new product-specific component in isolation.
• Refactored Old Code: Took the initiative to update legacy code to use system tokens or patterns.
• Shared Product Challenges: Communicated specific use case difficulties to the system team that could inform future work.
• Acknowledged System Complexity: Showed understanding that design system work is hard, muddy, and involves change.
• Understood FOF-End Gap: Recognized the importance of the “front of the front-end” layer and the skill involved.
• Talked DS Impact in Review: Mentioned how the system (foundations, patterns, etc.) helped their team achieve goals in a project review.
• Applied System Accessibility: Proactively followed the system’s accessibility guidance in their product work [2, implied guidance].
• Trained a Teammate (!!): Took the time to onboard or teach a colleague how to use system tokens or patterns effectively.
• Used Docs First (!!!): Found the answer in the documentation before asking the system team directly.
• Didn’t Complain (!!!!): Navigated a system limitation without expressing frustration to the system team [general difficulty of the work 66, 67].
• Asked if Comp Belongs: Sought input from the system team before assuming a product-specific component should be added to the core system.
• Identified Non-Comp Need: Pointed out a strategic or educational need for the system, beyond just adding components.
• Saw DS as Project Tool: Framed the use of system assets/principles as a strategic way to deliver their project’s business outcomes.
• Prioritized Token Usage: Consciously chose to apply system tokens rather than hardcoding values, even with a third-party library.
• Bridged Designer/Dev Gap: Used the system as a common language or tool to improve collaboration between product design and engineering.
• Showed Pattern Alignment: Demonstrated their UI adhered to system interaction or layout patterns during a demo or review.
• FREE SPACE: Made DS Team Feel Valued: Expressed appreciation or showed concrete ways the system helps them.

---

Going back to the “adoption bingo” that you did 2 prompts ago – can you now help me with talking points to sell the organization’s leadership on why devs are suddenly bothering to tell them all this? On what’s in it for the organization that they’re advertising what kinds of “adoption” they’re up to?

Okay, let’s reframe those “adoption bingo” wins into talking points designed to impress organizational leadership. The goal is to translate developer actions into language that speaks to business value and the strategic impact of the Design System investment, drawing directly from the sources and our conversation history.

Here’s how you can sell leadership on why teams highlighting their “adoption” efforts is valuable:

Product development teams are proactively reporting on their Design System engagement to demonstrate how they are leveraging organizational investments and contributing to key business objectives. This reporting highlights various forms of system “adoption” that go beyond just component usage, showing tangible progress in ways leadership cares about:

• Driving Consistency and Cohesion: Teams applying system tokens for color, typography, and spacing, or following system layout and interaction patterns, directly contributes to a unified product family experience. This ensures our users see a cohesive brand, regardless of which product or component library they interact with. This is foundational to achieving “efficient cohesion”.
• Accelerating Development & Improving Efficiency: By utilizing the system’s foundational assets (like tokens) to theme components (even from third-party libraries), teams avoid reinventing common UI elements from scratch. This allows them to move quickly (“speed mode”), focus on product-specific features, and reduce redundant work, saving significant development time.
• Enhancing Product Quality & Reducing Technical Debt: Teams are using the system’s guidance on accessibility, proactively refactoring older code to use system tokens/patterns, and reporting or fixing system bugs. These actions directly improve the stability, maintainability, and quality of our products, reducing future support and development costs.
• Fostering Collaboration & Knowledge Sharing: Teams engaging with the system team, providing feedback, asking insightful questions, and even training their own teammates on system usage builds a shared understanding. This bridges the gap between design and engineering and reduces the direct support burden on the core system team.
• Demonstrating Strategic Alignment: By focusing on applying system principles and foundations rather than demanding custom components for unique needs, teams are demonstrating their understanding of the system’s intended scope and strategic goals. They are showing how the system serves as a strategic tool to achieve their project’s business outcomes.
• Validating Investment Return: Highlighting these diverse forms of “adoption” (from using tokens and docs to contributing fixes) shows that the organization’s investment in the Design System is translating into tangible changes in how teams work and is helping make the system “something they can’t do their jobs without”, thus proving its value.

In essence, these “adoption” reports signal that product teams are actively engaging with the Design System’s strategic intent and foundational assets, even while tactically leveraging existing tools (like third-party libraries) where appropriate. This multi-faceted approach to adoption is crucial for achieving the organizational-level benefits of consistency, efficiency, and collaboration that the system is designed to deliver.

---

What 3 things, said in 1 short sentence, from your previous answer do you think Ben & Elyse would say are the most important benefits to the organization of the “adoption” (ahem!) reporting work that product teams are now starting to do?

Based on the sources and our conversation history, Ben and Elise would likely highlight these three important benefits to the organization from product teams reporting on their diverse forms of “adoption”:

• It shows concrete steps towards consistency and efficiency goals. This speaks directly to the core promises of a design system that leadership finds easy to understand and sell, demonstrating that the investment is leading to tangible alignment and reduced redundant effort.
• It proves the system is actively changing how product teams work. This goes beyond mere component usage to show the crucial “organizational behavior change” needed for the system to succeed. Reporting on actions like using documentation, attending sessions, or training peers highlights the education and engagement efforts that truly shift practices.
• It demonstrates teams are leveraging the system as a strategic business tool. By connecting system principles (even through actions like using tokens or discussing cohesion/speed) to their product work and project goals, teams show that the system isn’t just a library but a means to achieve broader organizational priorities. This helps leadership see the return on investment beyond just the existence of assets.

---

What kinds of alignment, reduced redundant effort, organizational behavior/practice shifts/change, strategic business efforts, ROI, and broad organizational priority achievement do you see in the “Adoption” bingo ideas you generated? (Now available as a source.)

The “Adoption Bingo” items highlight diverse developer actions that demonstrate valuable contributions to organizational goals, reframing system “usage” to include strategic and foundational engagement beyond just components. These actions signal progress in several key areas:

• Consistency and Alignment: Actions like “Applied System Tokens”, “Followed System Layouts”, “Used System Naming” [implied by tokens/patterns], and “Used a Component (Properly)” [implied by patterns] show teams are actively using the system’s foundational elements and patterns to build user interfaces. This directly contributes to the goal of efficient cohesion and creating a unified product family experience across the organization.
• Reduced Redundant Effort & Efficiency: By “Didn’t Ask for Component”, “Themed a 3rd-Party”, “Avoided Component Trap”, and “Avoided Product-Specific Comp”, teams demonstrate they are leveraging existing resources (whether system components or external libraries themed with the system) instead of building net-new custom solutions unnecessarily. This helps the organization move in “speed mode” and saves significant development time and maintenance cost, contributing to operational efficiency.
• Organizational Behavior/Practice Shifts: Items like “Attended System Session”, “Read System Docs”, “Provided Token Feedback”, “Briefly Paired w/ DS Team”, and especially “Trained Colleague on Tokens” are clear indicators that teams are actively engaging with the system team, learning how to use the system effectively, and even spreading that knowledge internally. This represents the crucial organizational behavior change required for a system to succeed, moving beyond just providing assets to truly changing how teams work.
• Strategic Business Efforts & Priorities: When developers “Aligned w/ Core Principles”, “Mentioned ‘Cohesion’“, “Talked ‘Speed Mode’“, “Cited ‘Org Change’“, “Discussed ‘Impact’“, and “Leveraged System for X (X=Project)”, they are demonstrating an understanding of the system’s broader purpose and connecting its use directly to strategic organizational goals like cohesion, efficiency, and project success. This shows the system is seen and used as a strategic tool to achieve business outcomes, not just a collection of UI elements.
• ROI & Proving Value: The sum of these actions, ranging from basic token usage and reading docs to more advanced contributions like “Reported a Real Bug” [implied] or “Contributed a Fix” [implied], providing feedback, and demonstrating impact on project goals, provides concrete evidence that the organization’s investment in the Design System is being leveraged and is translating into tangible improvements in consistency, efficiency, and the quality of how products are built. This multifaceted reporting on adoption, viewed broadly, helps show value and makes the system something teams “can’t do their jobs without”.
• Product Quality & Maintenance: While not every item maps directly, actions like “Applied System Accessibility” [2, implied] and “Refactored Old Code” (especially towards token usage) show teams improving the baseline quality and maintainability of the codebase, reducing technical debt, which is a long-term benefit for the organization. Reporting actual issues (“Reported a Real Bug”) also directly improves the system’s quality.

---

What are the best contributions that product teams can make with respect to consuming a company’s design system if they want to be “good citizens” of that company?

Based on the sources and our conversation history, the “best contributions” that product teams can make as “good citizens” when consuming a company’s design system involve a shift in how they work and a deeper engagement than just pulling in components. These contributions demonstrate value and support organizational goals in ways leadership cares about:

• Shifting their way of working to align with system practices and principles. This means actively changing how they build, applying the system’s foundational elements like tokens for color, typography, and spacing, following system layout and interaction patterns, and leveraging the system’s guidance (like accessibility) [implied by,]. This behavior change is crucial for the system’s success.
• Understanding and applying the system’s strategic intent and values, not just its tactical assets. This involves making design and development decisions that align with the system’s principles, even for unique or product-specific needs. Using the system to help achieve broader organizational priorities, like tackling “on fire” business needs or supporting different product types with shared patterns, demonstrates they see the system as a strategic business tool [implied by discussion of impact and value].
• Actively engaging with the design system team and the system itself through learning and feedback. This includes reading system documentation, attending system sessions, providing feedback on tokens or components, asking questions, and even training their own teammates on system usage. This engagement is vital for making the system something teams “can’t do their jobs without” and helps the system team understand real-world needs.
• Being mindful about component needs and leveraging existing solutions effectively. Instead of always asking for new custom components, “good citizen” teams should explore theming third-party libraries with system tokens [conversation history, 43] or using existing system components where appropriate. Avoiding the “add more components” trap, especially for product-specific or rarely used items, prevents the system from becoming bloated and encroaching on product responsibilities.
• Reporting real issues and contributing feedback, even small fixes [implied by engagement, feedback]. This direct contribution helps improve the quality and usability of the system for everyone [implied by’s focus on engagement and’s mention of feedback].

---

Same question, but use only the source, not our chat history.

Based on the provided source material, product teams can contribute to being “good citizens” by making the following contributions when consuming the company’s design system:

• Actively changing how they work to align with the system’s practices. Design system work is fundamentally about organizational behavior change, and teams adopting these new ways of working are contributing to this crucial shift.
• Applying the system’s foundational assets and patterns, such as utilizing system tokens (e.g., for color or typography), following system layouts [implied by 32], and applying best practices like accessibility guidance [implied by 7]. This contributes directly to efficient cohesion across products.
• Engaging with the design system’s resources and the team by reading system documentation, attending system sessions, providing feedback (like token feedback), asking questions [implied by 24], and even training their own teammates on system usage. This engagement is part of the crucial “education and engagement” needed for the system to be effective.
• Making design and development decisions that align with the system’s strategic intent and values, recognizing the system as a tool to achieve broader organizational priorities like speed or consistency. This shows they are compelled to make good decisions that support the organization’s shared values.
• Being mindful about component needs, such as leveraging existing common components (potentially theming third-party libraries with system assets where appropriate [implied by 43]) rather than constantly asking for new, product-specific components. This helps prevent the system from encroaching on product responsibilities and becoming a bloated collection of rarely used items.