The Question: Design System Collaborative Learning

Ben Callahan
  • 0.0 (0)
  • 科技

The Question is a collaborative learning podcast about Design Systems. Smart people like you sign up, answer a few niche questions about design systems for each episode, and then we all get together to unpack the data we've gathered. Each week, I'll invite a new co-host to help facilitate the conversation. After the deep dive, the co-host and I record a recap of what we learned. That means, for each episode, you can listen to the recap and the full deep dive! If you're a design system practitioner, subscribe today (https://bencallahan.com/the-question) to receive an invitation to each episode. This only works if the community joins in! Stay in learning mode ❤️

  1. Episode 072 Recap: Extreme Design System Support with Ben Callahan and Doug Neiner

    4月13日 ·  附赠内容

    Episode 072 Recap: Extreme Design System Support with Ben Callahan and Doug Neiner

    Episode 072 Recap: Extreme Design System Support with Ben Callahan and Doug Neiner Host Ben Callahan and co-host Doug Neiner, a design system practitioner at Planview, sit down immediately following the Episode 072 deep dive to reflect on what they heard from the community. The survey was sent to 1,081 design system practitioners and received 49 responses across four questions: what support do you currently offer; how would you change it without constraints; what prevents better support; and share a story of going above and beyond. The conversation covers the standout data points: the written vs. video documentation gap, the surprisingly high rate of dev environment access, embedding, private vs. public support channels, the balance between high-touch support and burnout, and the importance of being perceived as a helper rather than a blocker. Show Notes 00:00 - Introduction and episode overview 01:46 - Q1 data highlights: written vs. video documentation gap 02:13 - Dev environment access: higher than expected at nearly 50% 02:48 - Lowering the bar for video production with modern tooling 03:15 - The perfectionist/design system practitioner Venn diagram 04:00 - Q3 data: unclear ownership is low; headcount and competing priorities dominate 04:30 - What "competing priorities" really means for system teams 05:46 - Doug's support approach at Planview: docs, Slack channels, onboarding, and local debugging 07:53 - Going beyond "access": running consumer products locally for deeper support 08:28 - The most extreme example: getting an org-issued PC to support a heavy product 09:42 - DMs vs. open channels: why private requests matter for trust 10:34 - Not everyone is comfortable asking publicly—meeting people where they are 11:20 - The problem with ticketing systems and over-streamlining support11:49 - How private support builds trust that eventually leads to public participation 13:25 - Prioritizing relationship over efficiency: creating tickets on behalf of consumers 14:10 - Scale vs. effort framework for thinking about support types 15:42 - Embedding: initially looks high-effort/low-scale, but the impact compounds 16:21 - Doug on embedding: modeling behavior, referencing docs together, building self-sufficiency 17:50 - The other side: high-touch support and the risk of design system team burnout 18:47 - How to gauge when a support request warrants deep mentorship vs. a quick fix 21:56 - Recap of embedding discussion: Sean's reverse embedding process from Spotify 23:28 - Doug's one experience with reverse embedding and its lasting impact 24:06 - Alexander's story: misaligned incentives can undermine embedding programs 25:08 - Rebecca's insight: being a helper vs. a blocker, and how hard trust is to rebuild 26:06 - What embedding teaches you about your own system's pain points 26:31 - Staying connected to product work keeps system teams grounded in consumer reality 27:31 - Mapping stakeholders: identifying high-influence non-advocates and converting them 28:35 - Doug: influence can come from the product, not just the person 29:57 - AI in design system support: useful for self-service, but reduce touch points with caution 31:01 - Closing reflections and thanks 31:39 - Outro Where to Find the Hosts Ben Callahan is Founder of Sparkbox and Redwoods Design System Community. Read his writings, have him present at your event, or engage with him as a coach or consultant at https://bencallahan.com Doug Neiner is a Principal Software Engineer at Planview. Connect with him on LinkedIn. Get the Raw DataAccess the complete survey data from Episode 072 to conduct your own analysis: **https://bit.ly/41H6Tf7** Review the FigJam NotesDig into the collaborative notes we took as a community during the deep dive: **https://bit.ly/4mm3uLZ** Join the ConversationThe Question explores design systems topics through community research and deep-dive discussions. Participate in future episodes and contribute to the next survey: **https://bit.ly/answerTheQuestion**

    32 分钟
  2. Episode 072 Deep Dive: Extreme Design System Support with Ben Callahan and Doug Neiner

    4月13日

    Episode 072 Deep Dive: Extreme Design System Support with Ben Callahan and Doug Neiner

    Episode 072 Deep Dive: Extreme Design System Support with Ben Callahan and Doug Neiner Host Ben Callahan is joined by co-host Doug Niner, a design system practitioner at Planview, to explore extreme design system support—what it looks like, what gets in the way, and what truly moves the needle with consuming teams. The survey was sent to 1,081 design system practitioners and received 49 responses across four questions: what support do you currently offer; how would you change your program if unconstrained; what prevents better support; and share a story of going above and beyond. The conversation covers the surprising prevalence of dev environment access, the rarity and outsized impact of embedding, the tension between high-touch support and burnout, and why building trust may matter more than any specific tactic. Show Notes 00:00 - Introduction and welcome 00:37 - Guest background: Doug Niner on getting into design systems at Planview 01:38 - Topic framing: what is "extreme design system support"? 02:07 - Survey overview: the four questions asked 03:34 - Survey stats: 1,081 sent, 49 responses 03:59 - Q1 findings: what support are teams currently offering? 04:30 - Reactions: video vs. written docs, dev environment access 05:27 - Video documentation: perfectionism vs. "good enough" screen recordings 06:25 - Q3 findings: headcount, bandwidth, and competing priorities dominate 07:17 - Key insight: teams know what good looks like but lack people and time 09:10 - Embedding: high effort, but potentially exponential impact through advocacy 10:10 - Community discussion: what does "embedding" actually mean? 11:07 - Sean shares his team's embedding process: runbooks and buddy systems 15:36 - Alexander: forward embedding failures vs. reverse embedding wins 17:53 - Reverse embedding: consuming team members join the design system team 19:50 - Disruption and ROI: is onboarding a stream of embeds worth it? 21:16 - Turning embedded team members into lasting design system advocates 23:09 - Rapid bug turnaround as a trust-building extreme support tactic 24:57 - Embedded collaborators as a source of honest, continuous feedback 25:53 - "Runners": rotating on-call support roles and AI-assisted quick fixes 26:45 - Rebecca on trust: being a helper vs. a blocker 27:14 - Supporting private requests alongside public channels 28:35 - Over-systematizing support and why removing friction builds trust 29:31 - Q4 stories: going above and beyond for consuming teams 29:43 - Taylor's story: building buy-in for a generational system change at Fidelity 33:12 - Doug's story: burning trust with a team and winning them back over 18 months 34:37 - Mapping stakeholders from saboteur to advocate 35:30 - Jane's perspective: extreme support drives adoption but risks burnout 36:53 - Hand-holding vs. empowerment: when is high-touch support too much? 37:19 - Transitioning from high-touch support to self-service empowerment 43:51 - Live prototyping as a low-effort, high-value support approach 45:15 - Figma detachable components and slots discussion 45:50 - Christine's bi-weekly demo program at office hours 47:56 - Closing reflections; encouragement to read Q4 survey answers 48:25 - Community updates: Redwoods, Design System Triage, Converge in Newcastle 50:09 - Outro Where to Find the Hosts Ben Callahan is Founder of Sparkbox and Redwoods Design System Community. Read his writings, have him present at your event, or engage with him as a coach or consultant at https://bencallahan.com Doug Neiner is a Principal Software Engineer at Planview. Connect with him on LinkedIn. Get the Raw DataAccess the complete survey data from Episode 072 to conduct your own analysis: https://bit.ly/41H6Tf7 Review the FigJam NotesDig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4mm3uLZ Join the ConversationThe Question explores design systems topics through community research and deep-dive discussions. Participate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

    51 分钟
  3. Episode 071 Deep Dive: The Criticality of Design Systems with Ben Callahan & Vitaly Friedman

    3月29日

    Episode 071 Deep Dive: The Criticality of Design Systems with Ben Callahan & Vitaly Friedman

    Episode 071 Deep Dive: The Criticality of Design Systems with Ben Callahan & Vitaly Friedman In Episode 071, host Ben Callahan is joined by co-host Vitaly Friedman—UX Lead, author, and founder of Smashing Conference—for a deep dive into the criticality of design systems. Vitaly brings experience from complex enterprise environments, including a multi-year engagement consolidating 199 European Parliament websites into one across 25 languages. The survey was sent to over 1,000 design system practitioners, yielding 61 responses. Participants were asked four questions through the lens of their single most critical product: (1) what level of impact would a product failure have on end users—loss of comfort, discretionary money, essential money, or life; (2) the size of their engineering team; (3) how they ensure their design system supports that criticality; and (4) whether anyone in their org is doing workflow analysis with users. Show Notes00:04  Introduction and episode overview01:48  Vitaly's background: complex systems, B2B, insurance, European Parliament03:01  The pressure of high-stakes work and measuring before/after impact05:19  Ben's upcoming book, published by Smashing Magazine05:44  Survey overview: methodology and FigJam data access06:11  Q1 Results: 57% selected "loss of essential money"; write-in responses07:08  Q2 Results: even distribution across team sizes; Cockburn's scale model08:03  Vitaly on loss of trust and reputation as missing modern categories09:29  Expanding the criticality framework for today's digital landscape10:52  Defining workflow analysis vs. task analysis14:33  Financial app example: importing a portfolio (task) vs. market analysis (workflow)15:56  Key finding: workflow analysis correlates with team size, not criticality17:23  Peter: using AI agents as a team of one to conduct workflow analysis19:41  Community discussion: respondents who selected "loss of life"20:09  David (Mayo Clinic): design system tokens and cascading patient-room risk21:32  Taylor: higher criticality means more questions and stakeholders, not a different process23:52  Vitaly: poor data visualization choices can cascade into financial loss24:20  Reference: The Fifth Discipline by Peter Senge (1990)25:08  Hattie (John Deere): autonomous vehicle safety warnings and multi-team sign-off26:41  Jesse (NAVA): public benefits delivery—if this fails, someone doesn't eat28:10  Vitaly: legacy systems as an underappreciated source of fragility and criticality30:06  Taylor: legacy is an iceberg—you don't know what you've got until you knock31:58  Kele: integrating a design system and AI tooling into existing enterprise SaaS33:17  Level-setting AI expectations with leadership35:42  Greg: AI tooling as a potential accelerator for legacy accessibility migration39:38  Vitaly: migrating away from legacy means designing the change, not just the UI40:06  Ben: FOMO-driven AI adoption decisions41:32  Taylor: legacy systems are often politically protected44:15  Ben: systems thinkers evaluated on product KPIs—structural misalignment46:35  Kele: reframing "healthy tension" as creative friction with different mandates49:22  Closing and thank-yous49:48  Redwoods membership, UX London, previous episode with Hannah Where to find the hostsBen Callahan is Founder of Sparkbox and Redwoods Design System Community. Read his writings, have him present at your event, or engage with him as a coach or consultant at https://bencallahan.com Vitaly Friedman is a UX Lead and founder of Smashing Conference. Connect with him on LinkedIn: https://bit.ly/43Iig8B Get the Raw DataAccess the complete survey data from Episode 071: https://bit.ly/4rYcRTk Review the FigJam notesDig into the collaborative notes from the deep dive: https://bit.ly/4bKWSlt Join the conversationParticipate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

    52 分钟
  4. Episode 071 Recap: The Criticality of Design Systems with Ben Callahan & Vitaly Friedman

    3月29日 ·  附赠内容

    Episode 071 Recap: The Criticality of Design Systems with Ben Callahan & Vitaly Friedman

    Episode 071 Recap: The Criticality of Design Systems with Ben Callahan & Vitaly Friedman IntroductionHost Ben Callahan and co-host Vitaly Friedman reflect on the insights from the Episode 071 deep dive on the criticality of design systems. Vitaly is a UX lead, founder of Smashing Conference, and practitioner working in complex enterprise environments—most recently with the European Parliament. The survey was sent to 1,069 design system practitioners and received 61 responses. Respondents were asked four questions through the lens of their single most critical product: how failure would impact end users (loss of comfort, discretionary money, essential money, or life); the size of the engineering team; how their design system supports that criticality and scale; and whether anyone in their org is doing workflow analysis with product users. Show Notes00:00 - Welcome and introductions; Vitaly reflects on surprises from the deep dive00:27 - How The Question works: survey Monday, deep dive Thursday, recap to follow01:41 - The Coburn Scale and how it shaped the survey questions03:45 - Survey results: why "loss of essential money" topped the criticality scale04:23 - Vitaly's take: loss of reputation and trust as proxies for financial loss05:30 - Write-in responses: loss of transparency, essential data, and future compatibility07:28 - Hyper-personalization and ephemeral UI: validating experiences we can't fully see08:50 - Decisions as infrastructure: encoding decisions into markdown and design systems11:57 - Automation and AI across design, code, and UI—and what that means for human oversight13:52 - "Flying blind": the risks of building layers atop systems we don't fully understand16:30 - Defining workflow analysis vs. task analysis and why it matters19:37 - The hypothesis: does higher criticality correlate with more workflow analysis? The data didn't confirm it.22:01 - What the data did show: team size as a stronger predictor than criticality25:32 - Design systems sandwiched between product teams and top-down quality guidelines29:35 - Legacy software: an underappreciated risk factor and political minefield32:39 - Migrating legacy means migrating flows, habits, and ways of working—not just UI34:46 - What Vitaly is working on: events, video courses, design patterns, and upcoming books36:14 - How to stay connected; Redwoods community open for membership --- Where to Find the HostsBen Callahan is Founder of Sparkbox and Redwoods Design System Community. Read his writings, have him present at your event, or engage with him as a coach or consultant at https://bencallahan.com Vitaly Friedman is a UX Lead and founder of Smashing Conference. Connect with him on LinkedIn https://bit.ly/43Iig8B Get the Raw DataAccess the complete survey data from Episode 071 to conduct your own analysis: https://bit.ly/4rYcRTk Review the FigJam NotesDig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4bKWSlt Join the ConversationThe Question explores design systems topics through community research and deep-dive discussions. Participate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

    38 分钟
  5. Episode 070 Deep Dive: Lasting Design System Infrastructure with Ben Callahan & Hannah Clarke

    3月16日

    Episode 070 Deep Dive: Lasting Design System Infrastructure with Ben Callahan & Hannah Clarke

    Introduction Host Ben Callahan is joined by co-host Hannah Clarke, UI Engineer at Intapp, for a live deep dive on building design system infrastructure that lasts. The survey went to 1,061 practitioners and received 45 responses across four questions: company leadership model, dedicated team roles, who owns coded component delivery, and what actions create a system that endures. The conversation spans surprising results, web component delivery strategies, the framework agnostic debate, the unicorn-hire problem, API flexibility, and the human community that makes any system worth building. This episode is made possible by Mintlify. If your design system documentation lives in five places and satisfies no one, Mintlify can provide one beautiful, AI-powered home for everything your team builds (and the why behind those decisions).Try it free → https://bit.ly/try-mintlify (use code MINT-THEQ for 50% off Pro for 6 months) Show Notes 00:02 — Welcome, Hannah's intro, and sponsor message (Mintlify) 01:07 — Hannah's background: UI Engineer at Intapp, full-stack roots, how she found the design systems space 03:25 — Survey overview: Four questions, 1,061 sent, 45 responses 04:39 — Q1: "Led by product" came in at ~40%, surprising Ben; Hannah less shocked given her experience 06:31 — Q2: Front-end dev outranked UI design in dedicated roles; reference to Sean Bent's post on design system hiring trends 08:22 — Community as infrastructure: Awareness and human connection matter as much as tooling; user showcase idea from Hannah's team retro 11:14 — Joshua: In-person labs where consuming teams experiment with the design system to make it feel engaging 12:13 — Hannah's delivery approach: Stencil + web components, outputting to multiple NPM packages (tokens, styles, web components, React 18, React 19 + SSR) 14:33 — Q4 theme: Framework agnosticism as a longevity strategy; design-side agnosticism and Penpot as a Figma alternative 16:50 — Josh: Journey from web components wrapped in React to going all-in on React and why 17:48 — Real challenges wrapping web components for React: Shadow DOM, team culture resistance, the "pure React" demand 19:09 — Post-processing scripts on top of Stencil: Default values, required props, types files, and developer quality-of-life improvements 22:50 — Guy: AI workflow from Figma to production code; using Figma Console MCP to convert prototypes into design-system-compliant files; circumventing design tools altogether 27:11 — Kelly: Laid off with her entire product design org; job postings pitting design vs. engineering; the value of tight cross-discipline collaboration 30:54 — Hannah: The full-stack cycle — companies oscillate between specialists and generalists at their own peril 32:23 — Greg: Flipping the unicorn question — even if unicorns existed, would they want to do everything expected of them? 36:05 — Amy: Designers vibe coding directly in repos; how design systems can support that workflow and reduce chaos 37:31 — Joanna: Built two full implementations (React + Angular) after teams refused a framework-agnostic approach; the real costs 39:30 — Sean: Extending across iOS + Android; shared tokens, consistent naming, cross-platform rituals; treating Figma as a fourth platform 41:22 — Managing cross-platform parity: Manual processes, shared style layers, prioritization by demand 44:09 — Hannah: Why she moved away from "just React" thinking; the unsolved mobile challenge for a three-person team 46:36 — API flexibility vs. rigidity: Joanna's case for flexible APIs; Hannah and Mike on finding the balance without losing consistency 51:01 — Closing remarks and community announcements Where to Find the Hosts Ben Callahan, Founder of Sparkbox and Redwoods Design System Community: https://bencallahan.com Hannah Clarke, UI Engineer at Intapp: https://bit.ly/47kl2ln Get the Raw Data: https://bit.ly/3OOuU0B Review the FigJam Notes: https://bit.ly/4rxa9E8 Join the Conversation: https://bit.ly/answerTheQuestion

    53 分钟
  6. Episode 070 Recap: Lasting Design System Infrastructure with Ben Callahan & Hannah Clarke

    3月16日 ·  附赠内容

    Episode 070 Recap: Lasting Design System Infrastructure with Ben Callahan & Hannah Clarke

    Episode 070 Recap: Lasting Design System Infrastructure with Ben Callahan & Hannah Clarke This episode is made possible by Mintlify. If your design system documentation lives in five places and satisfies no one, Mintlify can provide one beautiful, AI-powered home for everything your team builds (and the why behind those decisions).Try it free → https://bit.ly/try-mintlify (use code MINT-THEQ for 50% off Pro for 6 months) IntroductionIn Episode 070 of The Question, host Ben Callahan sits down with co-host Hannah Clarke, UI Engineer at Intapp, to recap a conversation about building design system infrastructure that lasts. The episode drew from a survey sent to 1,061 design system practitioners, yielding 45 responses across four questions: which leadership model best describes your company (engineering, product, design, or balanced); which roles have at least one dedicated person on your design system team (DevOps, design ops, UI design, front-end dev); who owns responsibility for delivering coded components; and what actions create a system that endures. The conversation ranges from surprising survey results and the unicorn-hire debate to web component delivery strategies, framework agnosticism, and the human infrastructure that keeps systems alive. Show Notes00:00 — Welcome & sponsor mention (Mintlify)00:45 — Survey methodology recap: 1,061 sent, 45 responses, four questions reviewed01:20 — Q1 results: Company leadership — "led by product" dominated; why that surprised Ben but not Hannah02:35 — Low "led by design" responses: what does that say about design's seat at the table?04:47 — Q2 results: Dedicated roles — front-end dev outranked UI design, which shocked both hosts05:35 — Job posting trends: Why available design system roles skew toward design over engineering06:49 — The unicorn problem: Companies asking for one person to do it all07:20 — Greg's insight from the deep dive: "I want to use my code knowledge to do my design job better"08:01 — Hannah's perspective: Understanding design makes you a better front-end developer, but specialisms matter09:10 — Q4 highlight: "Connecting people that ask about the system — tools will keep changing, but people will keep interest alive"10:02 — Human infrastructure: Why community-building is as foundational as technical tooling11:36 — Data note: Over 60% of Q4 responses mentioned humans, people, community, champions, or trust12:22 — The cultural hurdle: Solving a technical problem doesn't mean people will adopt it13:13 — Framework agnostic vs. framework-specific: Three respondents advocated for agnosticism; Joanna's team built two separate libraries14:08 — Hannah's approach at Intapp: Why they chose Stencil + web components and the longevity thinking behind it15:43 — How they actually deliver components: NPM packages for tokens, styles, web components, React 18, and React 19/SSR18:49 — Post-processing scripts on top of Stencil: Default values, required props, types files, and developer quality-of-life improvements20:26 — Lowering the barrier to adoption: Making it painless for consuming teams to say yes21:38 — Working with teams already using Material UI: Not replacing everything, but filling the gaps24:07 — What does DevOps actually mean on a design system team day-to-day?26:14 — Hannah's surprising reality: Nearly 100% of her time is infrastructure, not component-building28:04 — Design-side agnosticism: Is Figma-lock sustainable? What Guy's team is doing differently29:30 — Treating Figma as a platform (alongside iOS, Android, web) — a mindset for longevity30:16 — Documentation-driven implementation: Defining the component as data first, then expressing it in any tool31:23 — Closing thought: Systems that last are defined above the tools, not inside them Where to Find the HostsBen Callahan is Founder of Sparkbox and Redwoods Design System Community. Read his writings, have him present at your event, or engage with him as a coach or consultant at https://bencallahan.com Hannah Clarke is a UI Engineer at Intapp. Connect with her on LinkedIn: https://bit.ly/47kl2ln Get the Raw DataAccess the complete survey data from Episode 070 to conduct your own analysis: https://bit.ly/3OOuU0B Review the FigJam NotesDig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4rxa9E8 Join the ConversationThe Question explores design systems topics through community research and deep-dive discussions. Participate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

    32 分钟
  7. Episode 069 Recap: Rebuilding a Design System Mid-Flight with Ben Callahan & Shimma Hassan

    3月2日 ·  附赠内容

    Episode 069 Recap: Rebuilding a Design System Mid-Flight with Ben Callahan & Shimma Hassan

    Episode 069 Recap: Rebuilding a Design System Mid-Flight with Ben Callahan & Shimaa Hassan --- Introduction In Episode 069 of The Question, host Ben Callahan (founder of Sparkbox and Redwoods Design System Community) sits down with co-host Shimaa Hassan. The conversation centers on one of the most persistent challenges in design systems work: how do you rebuild the foundation while the plane is still flying? Ben and Shimaa share survey results from 1,061 design system practitioners (53 responses) and open the floor to a rich community discussion on versioning strategies, token architecture, breaking changes, and the ongoing tension between innovation and standardization. Survey questions asked: (1) How many times a month do you think about throwing your design system away and starting over? (Range: 0–5) | (2) If you chose to start over, what's the one decision you'd make differently on day one? | (3) How do you keep product teams confident in a system that's actively being rebuilt underneath them? | (4) Tell us a story about rebuilding a system mid-flight. --- Show Notes0:05 — Introductions: Ben welcomes Shimaa Hassan as co-host for episode 690:18 — Episode context: rebuilding a design system mid-flight and how Ben and Shimaa connected1:00 — Survey recap: the "how often do you think about starting over?" question and why Shimaa expected a higher number1:36 — Data results: the ~50/50 split and overview of the three open-text survey questions2:30 — The "fork and maintain" approach: letting teams use the old version while building the new one3:19 — Shimaa's iterative approach: design rebuilt from scratch, engineering making incremental changes in code4:53 — Step-by-step walkthrough: how Shimaa used the existing codebase and AI tools to inform the new architecture7:29 — Systematizing what already exists: abstracting and naming tokens vs. inventing new ones8:10 — Avoiding breaking changes: the strategy of supporting the live state while layering in improvements9:29 — Finding the middle ground: honoring existing design before driving further evolution10:30 — Multiple versions vs. iterative: Guy's semantic versioning approach vs. smaller teams who can't maintain parallel systems13:30 — Taylor's poll: how few teams have actually had a formal, mandated migration period15:00 — A model for splitting system team responsibilities: dedicated evolution vs. embedded implementation support16:12 — Shimaa's experience at Square: rotation embeds and borrowing engineers between teams17:15 — Empathy building through team exchange programs: pros, cons, and the ambassador model18:22 — Standardization vs. innovation: is the design system the right place for innovation?19:34 — Reframing the idea: "the system enables product teams to innovate" and the danger of generic innovation mandates21:16 — Working with product teams: how to collaborate on patterns that are ready to be standardized22:13 — Closing thoughts and wrap-up --- Where to Find the HostsBen Callahan—Founder of Sparkbox and the Redwoods Design System Community. Individual and team coaching for design system programs. https://bencallahan.com Shimaa Hassan—Senior Product Designer at Remote, specializing in design systems. https://www.linkedin.com/in/shimaahassan/ --- Get the Raw DataAccess the complete survey data from Episode 069 to conduct your own analysis: https://bit.ly/46s0G9w --- Review the FigJam NotesDig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4aNvT8j --- Join the ConversationThe Question explores design systems topics through community research and deep-dive discussions. Participate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

    23 分钟
  8. Episode 069 Deep Dive: Rebuilding a Design System Mid-Flight with Ben Callahan & Shimaa Hassan

    3月2日

    Episode 069 Deep Dive: Rebuilding a Design System Mid-Flight with Ben Callahan & Shimaa Hassan

    Episode 069 Deep Dive: Rebuilding a Design System Mid-Flight with Ben Callahan & Shimaa Hassan IntroductionIn episode 069 of *The Question*, host Ben Callahan (founder of Sparkbox and the Redwoods Design System Community) sits down with co-host Shimaa Hassan to tackle one of the most universal challenges in the space: rebuilding a design system while the products it supports are still in production. Ben surveyed 1,061 design system practitioners and received 53 responses across four questions: a 0–5 range question asking how often respondents think about throwing their system away and starting over, plus three open-text questions — (1) what's the one decision you'd make differently on day one, (2) how do you keep product teams confident in a system being rebuilt underneath them, and (3) share a story about rebuilding mid-flight. Key themes include token architecture, composability, governance, and the honest reality of how rarely formal migration mandates get enforced. --- Show Notes - 00:02 — Welcome and intro- 00:27 — Shimaa's background: from Alexandria, Egypt to design systems at Square and Remote- 02:28 — Shimaa's current challenge: rebuilding at Remote while the product ships continuously- 04:46 — Survey methodology and overview of the four questions- 05:43 — Question 1 results: roughly 50/50 split; Ben's sentiment analysis of the extremes- 08:48 — Question 2 highlights: token architecture, simplicity, composability, governance, leading with documentation- 10:09 — Erin on a cross-platform parity audit (iOS, Android, web) and handling breaking changes- 11:36 — Shimaa on balancing live product state with new system decisions- 12:37 — Guy on semantic versioning: one major release per year, advance communication, and a CLI tool that automated 70% of breaking change migrations- 14:34 — Taylor on SLAs, defining "breaking change" for your system vs. the org, mono repo vs. component-level versioning- 17:45 — Maintaining parallel systems: running old and new simultaneously- 18:53 — Peter references Kim Williams' Clarity talk on managing system transitions- 22:36 — How do you get teams to actually switch? Selling the value of migration- 26:26 — Shimaa's pro tip: run the codebase locally; use AI to audit token usage and map point-A-to-point-B- 29:16 — Guy on mandates that exist on paper but aren't enforced; lower org maturity can work in your favor- 31:41 — Taylor on the system as a place of stability; introducing an "additive threshold" for governance- 36:50 — Shimaa on triage logs tagged "approved / will not do / future"- 38:19 — Peter on adaptable (not rigid) infrastructure; wanting early involvement with consuming teams- 42:07 — Taylor's feature status Airtable for centralizing and communicating request progress- 45:46 — Shimaa introduces Norma Labs: a space for ideas not yet mature enough for the core system- 47:06 — Aaron on component-level versioning with 20 components needing updates simultaneously- 48:30 — Tallulah and Liz on capacity constraints; offering support windows to encourage faster migration- 50:45 — Liz on her IBM experience building testing infrastructure to keep React and Angular in parity- 52:31 — Peter's closing mantra: "Don't show me different, show me better"- 53:01 — Shimaa's closing reflection; Ben's announcements --- Resources Mentioned- Kim Williams' Clarity Conference talk on transitioning between design systems (https://designsystems.media/video/kim-williams-start-with-your-brand-purpose/) --- Where to Find the HostsBen Callahan—Founder of Sparkbox and the Redwoods Design System Community. Individual and team coaching for design system programs. https://bencallahan.com Shimaa Hassan—Senior Product Designer at Remote, specializing in design systems. https://www.linkedin.com/in/shimaahassan/ --- Get the Raw DataAccess the complete survey data from Episode 069 to conduct your own analysis: https://bit.ly/46s0G9w --- Review the FigJam NotesDig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4aNvT8j --- Join the ConversationThe Question explores design systems topics through community research and deep-dive discussions. Participate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

    55 分钟
查看全部 15 集

关于

The Question is a collaborative learning podcast about Design Systems. Smart people like you sign up, answer a few niche questions about design systems for each episode, and then we all get together to unpack the data we've gathered. Each week, I'll invite a new co-host to help facilitate the conversation. After the deep dive, the co-host and I record a recap of what we learned. That means, for each episode, you can listen to the recap and the full deep dive! If you're a design system practitioner, subscribe today (https://bencallahan.com/the-question) to receive an invitation to each episode. This only works if the community joins in! Stay in learning mode ❤️

信息

你可能还喜欢