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 Notes
00:04  Introduction and episode overview
01:48  Vitaly's background: complex systems, B2B, insurance, European Parliament
03:01  The pressure of high-stakes work and measuring before/after impact
05:19  Ben's upcoming book, published by Smashing Magazine
05:44  Survey overview: methodology and FigJam data access
06:11  Q1 Results: 57% selected "loss of essential money"; write-in responses
07:08  Q2 Results: even distribution across team sizes; Cockburn's scale model
08:03  Vitaly on loss of trust and reputation as missing modern categories
09:29  Expanding the criticality framework for today's digital landscape
10:52  Defining workflow analysis vs. task analysis
14:33  Financial app example: importing a portfolio (task) vs. market analysis (workflow)
15:56  Key finding: workflow analysis correlates with team size, not criticality
17:23  Peter: using AI agents as a team of one to conduct workflow analysis
19:41  Community discussion: respondents who selected "loss of life"
20:09  David (Mayo Clinic): design system tokens and cascading patient-room risk
21:32  Taylor: higher criticality means more questions and stakeholders, not a different process
23:52  Vitaly: poor data visualization choices can cascade into financial loss
24:20  Reference: The Fifth Discipline by Peter Senge (1990)
25:08  Hattie (John Deere): autonomous vehicle safety warnings and multi-team sign-off
26:41  Jesse (NAVA): public benefits delivery—if this fails, someone doesn't eat
28:10  Vitaly: legacy systems as an underappreciated source of fragility and criticality
30:06  Taylor: legacy is an iceberg—you don't know what you've got until you knock
31:58  Kele: integrating a design system and AI tooling into existing enterprise SaaS
33:17  Level-setting AI expectations with leadership
35:42  Greg: AI tooling as a potential accelerator for legacy accessibility migration
39:38  Vitaly: migrating away from legacy means designing the change, not just the UI
40:06  Ben: FOMO-driven AI adoption decisions
41:32  Taylor: legacy systems are often politically protected
44:15  Ben: systems thinkers evaluated on product KPIs—structural misalignment
46:35  Kele: reframing "healthy tension" as creative friction with different mandates
49:22  Closing and thank-yous
49:48  Redwoods membership, UX London, previous episode with Hannah

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

Vitaly Friedman is a UX Lead and founder of Smashing Conference. Connect with him on LinkedIn: https://bit.ly/43Iig8B

Get the Raw Data
Access the complete survey data from Episode 071: https://bit.ly/4rYcRTk

Review the FigJam notes
Dig into the collaborative notes from the deep dive: https://bit.ly/4bKWSlt

Join the conversation
Participate in future episodes and contribute to the next survey: https://bit.ly/answerTheQuestion

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

Introduction
Host 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 Notes
00:00 - Welcome and introductions; Vitaly reflects on surprises from the deep dive
00:27 - How The Question works: survey Monday, deep dive Thursday, recap to follow
01:41 - The Coburn Scale and how it shaped the survey questions
03:45 - Survey results: why "loss of essential money" topped the criticality scale
04:23 - Vitaly's take: loss of reputation and trust as proxies for financial loss
05:30 - Write-in responses: loss of transparency, essential data, and future compatibility
07:28 - Hyper-personalization and ephemeral UI: validating experiences we can't fully see
08:50 - Decisions as infrastructure: encoding decisions into markdown and design systems
11:57 - Automation and AI across design, code, and UI—and what that means for human oversight
13:52 - "Flying blind": the risks of building layers atop systems we don't fully understand
16:30 - Defining workflow analysis vs. task analysis and why it matters
19: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 criticality
25:32 - Design systems sandwiched between product teams and top-down quality guidelines
29:35 - Legacy software: an underappreciated risk factor and political minefield
32:39 - Migrating legacy means migrating flows, habits, and ways of working—not just UI
34:46 - What Vitaly is working on: events, video courses, design patterns, and upcoming books
36:14 - How to stay connected; Redwoods community open for membership

---

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

Vitaly Friedman is a UX Lead and founder of Smashing Conference. Connect with him on LinkedIn https://bit.ly/43Iig8B

Get the Raw Data
Access the complete survey data from Episode 071 to conduct your own analysis: https://bit.ly/4rYcRTk

Review the FigJam Notes
Dig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4bKWSlt

Join the Conversation
The 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

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

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)

Introduction
In 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 Notes
00:00 — Welcome & sponsor mention (Mintlify)
00:45 — Survey methodology recap: 1,061 sent, 45 responses, four questions reviewed
01:20 — Q1 results: Company leadership — "led by product" dominated; why that surprised Ben but not Hannah
02: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 hosts
05:35 — Job posting trends: Why available design system roles skew toward design over engineering
06:49 — The unicorn problem: Companies asking for one person to do it all
07: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 matter
09: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 tooling
11:36 — Data note: Over 60% of Q4 responses mentioned humans, people, community, champions, or trust
12:22 — The cultural hurdle: Solving a technical problem doesn't mean people will adopt it
13:13 — Framework agnostic vs. framework-specific: Three respondents advocated for agnosticism; Joanna's team built two separate libraries
14:08 — Hannah's approach at Intapp: Why they chose Stencil + web components and the longevity thinking behind it
15:43 — How they actually deliver components: NPM packages for tokens, styles, web components, React 18, and React 19/SSR
18:49 — Post-processing scripts on top of Stencil: Default values, required props, types files, and developer quality-of-life improvements
20:26 — Lowering the barrier to adoption: Making it painless for consuming teams to say yes
21:38 — Working with teams already using Material UI: Not replacing everything, but filling the gaps
24: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-building
28:04 — Design-side agnosticism: Is Figma-lock sustainable? What Guy's team is doing differently
29:30 — Treating Figma as a platform (alongside iOS, Android, web) — a mindset for longevity
30:16 — Documentation-driven implementation: Defining the component as data first, then expressing it in any tool
31:23 — Closing thought: Systems that last are defined above the tools, not inside them

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

Hannah Clarke is a UI Engineer at Intapp. Connect with her on LinkedIn: https://bit.ly/47kl2ln

Get the Raw Data
Access the complete survey data from Episode 070 to conduct your own analysis: https://bit.ly/3OOuU0B

Review the FigJam Notes
Dig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4rxa9E8

Join the Conversation
The 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

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 Notes
0:05 — Introductions: Ben welcomes Shimaa Hassan as co-host for episode 69
0:18 — Episode context: rebuilding a design system mid-flight and how Ben and Shimaa connected
1:00 — Survey recap: the "how often do you think about starting over?" question and why Shimaa expected a higher number
1:36 — Data results: the ~50/50 split and overview of the three open-text survey questions
2:30 — The "fork and maintain" approach: letting teams use the old version while building the new one
3:19 — Shimaa's iterative approach: design rebuilt from scratch, engineering making incremental changes in code
4:53 — Step-by-step walkthrough: how Shimaa used the existing codebase and AI tools to inform the new architecture
7:29 — Systematizing what already exists: abstracting and naming tokens vs. inventing new ones
8:10 — Avoiding breaking changes: the strategy of supporting the live state while layering in improvements
9:29 — Finding the middle ground: honoring existing design before driving further evolution
10:30 — Multiple versions vs. iterative: Guy's semantic versioning approach vs. smaller teams who can't maintain parallel systems
13:30 — Taylor's poll: how few teams have actually had a formal, mandated migration period
15:00 — A model for splitting system team responsibilities: dedicated evolution vs. embedded implementation support
16:12 — Shimaa's experience at Square: rotation embeds and borrowing engineers between teams
17:15 — Empathy building through team exchange programs: pros, cons, and the ambassador model
18: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 mandates
21:16 — Working with product teams: how to collaborate on patterns that are ready to be standardized
22:13 — Closing thoughts and wrap-up

---

Where to Find the Hosts
Ben 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 Data
Access the complete survey data from Episode 069 to conduct your own analysis: https://bit.ly/46s0G9w

---

Review the FigJam Notes
Dig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4aNvT8j

---

Join the Conversation
The 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

Episode 069 Deep Dive: 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 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 Hosts
Ben 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 Data
Access the complete survey data from Episode 069 to conduct your own analysis: https://bit.ly/46s0G9w

---

Review the FigJam Notes
Dig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4aNvT8j

---

Join the Conversation
The 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

Episode 068 Part II Deep Dive: Design Systems as AI Context with TJ Pitre
Aired live: February 20, 2026

Introduction
In Part II of Episode 068, host Ben Callahan is joined again by co-host TJ Pitre—founder of Southleft, a front-end design development agency specializing in the intersection of AI and design systems—for a live community deep dive. This episode builds on Episode 068 Part I's exploration of the challenges that emerge when stochastic models try to keep the deterministic promises of a design system.

This week the question turned practical: what work needs to happen behind the scenes so your design system can serve as powerful, reliable AI context? Ben and TJ sent the question to 1,031 design system practitioners and received 184 responses. The community came ready to share—from MCP servers as structured sources of truth, to agentic feedback loops that validate component output against documentation, to honest debate about where Storybook fits in an AI-native workflow.

Show Notes
00:00 — Welcome; Ben sets context for the Part II deep-dive format
00:25 — TJ introduces Southleft and his team's focus on AI + design systems
04:00 — Opening the question: where does your design system live as AI context?
09:07 — Design System Assistant MCP vs. Claude Code-to-Figma: which is better for whom?
10:02 — "Vibe coding" and the emerging pattern of going from code → Figma for UI refinement
15:42 — Community discussion: single source of truth vs. federated systems
15:56 — Eric Steinborn: their source of truth spans JS docs, JSON tokens, Figma, a reference site, and Storybook — and the consolidation effort underway
19:57 — TJ's agentic feedback loop: docs → MCP → code generation → screenshot → validation → iteration
22:56 — Ismail Hamila's AI audit agent: agnostic formats, skills, and checking correct variable intent (not just correct variable usage)
31:18 — Orchestration layers, RAG, and vector databases as an alternative to forcing a single source of truth
31:45 — Ismail's cautionary tale: burning $10 of tokens on a poorly-architected first agent run
34:04 — FigJam spotlight: NY State team's pattern engine; Jennie Yip's design system as AI infrastructure diagram
44:12 — Where does Storybook fit? TJ makes the case for Storybook MCP (via Chromatic) depending on your team
45:35 — Jennie Yip: how packaging everything into an MCP server eliminated AI hallucination
48:04 — Kevin Muldoon in chat: "The blueprint is not derived from the building. Authority flows from origin, not from output."
50:46 — Wrap-up and gratitude for FigJam participation
54:04 — Ben's closing: raw data, FigJam, and coaching resources at https://bencallahan.com

Where to Find the Hosts
Ben Callahan is the founder of Sparkbox (https://sparkbox.com) and the Redwoods Design System Community (bencallahan.com/redwoods), and host of The Question (https://bencallahan.com/the-question). Find him on LinkedIn (https://bit.ly/3T6rd5S).

TJ Pitre is the founder of Southleft (https://southleft.com/). Find TJ on LinkedIn (https://bit.ly/4rsXOBf).

Get the Raw Data
Access the survey data for this episode here: https://bit.ly/4apfR5v

Review the FigJam Notes
Community notes from the deep dive: https://bit.ly/4c9cvFp

Join the Conversation
Subscribe to The Question and join the Redwoods community at https://bencallahan.com/thequestion.

Episode 068 Recap: Design Systems as AI Context with Ben Callahan & TJ Pitre

Introduction

Welcome to The Question Episode 068 Recap. In this episode, Ben Callahan and co-host TJ Pitre facilitate a deep dive into one of the most pressing topics in the design system space today: Are our design systems ready to serve as reliable AI context?

Ben sent a three-question survey to 1,031 design system practitioners and received 148 responses. The questions explored:

1. How prepared design systems are to act as reliable AI context
2. Whether teams are experimenting with AI-generated UI
3. How practitioners feel about the output—or what’s holding them back

What followed was a nuanced, honest conversation about infrastructure, documentation, design-to-dev parity, and the emotional tension many practitioners feel in this moment.

Show Notes

00:00 – Introduction & Topic Framing
Design systems as AI context and acknowledging the tension around AI.

06:38 – Survey Overview & Readiness Data
Why most teams feel underprepared—and why that matters.

11:51 – Experimentation vs. Confidence
Many are testing AI even if they don’t feel ready.

13:17 – What Does “AI Readiness” Actually Mean?
The gap between perceived readiness and actual infrastructure maturity.

14:14 – Figma as Canonical Source of Truth
How context cascades from design to development—and where it breaks.

16:11 – The Figma Bridge Experiment
Using APIs to extract component specs and generate code with AI.

17:05 – Discovering the Cracks
Detached components, hard-coded values, missing properties, and hidden inconsistencies.

20:18 – “Infrastructure Wins Over Prompting”
Why better prompting isn’t the answer—better system architecture is.

22:30 – Beyond Visual Fidelity
Metadata, ARIA labels, intent, and behavior as critical AI context.

24:44 – Documentation Drift & Context Sprawl
AI can’t distinguish outdated documentation without human governance.

29:25 – Design-to-Dev Parity Workflows
Using tooling to compare canonical sources and surface deviations automatically.

32:57 – AI as Passenger, Not Driver

Key Themes

1. Infrastructure > Prompting

The quality of AI output is directly tied to the integrity of your system. If your components are inconsistent, disconnected, or poorly documented, AI will expose those cracks—not fix them.

2. Context is the New Prompt

2024 was about prompts. 2025 is about context. Systems that encode intent, behavior, accessibility, and relationships between components will outperform purely visual libraries.

3. AI Reveals Design Debt

Detached components, missing properties, undocumented variants—AI makes hidden system debt visible.

4. Documentation Is a Living System

Outdated Confluence pages and static decks become liabilities when surfaced through LLMs. Human oversight and governance remain essential.

5. AI Should Be Embedded in Workflow

Not “set it and forget it.” Involve AI throughout design, parity checks, and documentation—not just at the end.

Where to Find the Hosts

TJ Pitre: Founder of Southleft and working at the intersection of design systems and AI.
https://southleft.com/

Ben Callahan: Host of The Question, Founder of Redwoods Design System Community and Founder of Sparkbox.
https://bencallahan.com
https://sparkbox.com

Get the Raw Data

Access the complete survey data from Episode 068 to conduct your own analysis: https://bit.ly/4apfR5v

Review the FigJam notes
Dig into the collaborative notes we took as a community during the deep dive: https://bit.ly/4c9cvFp

Join the Conversation

The 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

Episode 068 Recap: Design Systems as AI Context with Ben Callahan & TJ Pitre

Introduction
Welcome to The Question Episode 068 Recap. In this episode, Ben Callahan sits down with TJ Pitre—founder of South Left studio—to unpack the results from this week's survey on design systems as AI context.

Ben sent the three-question survey to 1,031 design system practitioners and received a record 148 responses. The questions explored how prepared design systems are to act as reliable AI context today, whether practitioners have experimented with AI-generated UI from their design systems, and how they feel about the output (or what's keeping them from trying). The conversation that follows is a recap of the deep dive into the emerging relationship between design systems and AI, revealing why infrastructure and context quality matter more than clever prompts when it comes to AI-assisted workflows.

---

Show Notes

00:00 - Introduction & Welcome
02:10 - Survey Overview & The Emotional Landscape of AI
03:27 - The Three Survey Questions
04:41 - Perception vs. Reality of AI Readiness
06:34 - Detached Components and Hidden Cracks
08:40 - AI Slop as a Signal for System Quality
09:32 - Can AI Eventually Infer Intent Without Clean Context?
11:09 - The Case for Human Involvement and Original Thought
13:31 - Compounding Slop: When AI Builds on Its Own Mistakes
14:28 - Context Engineering vs. Vibe Coding
15:06 - Evals: Having Your AI Check Your AI
17:48 - The Russian Doll Method: Building Systems Atomically
20:04 - Human Oversight in the AI Workflow Loop
20:44 - Infrastructure Wins Over Prompting
22:37 - Tools: Serena MCP and Sequential Thinking
23:56 - Closing Advice: Stay Curious, Start Small
25:42 - Getting Started: Claude Chat + Figma MCP
27:37 - The Most Impactful Change: Run Diagnostics on Your System
29:29 - Closing Reflections & What's Next

---

Resources Mentioned
- TJ's AI and Design Systems course: (https://https://aianddesign.systems//)
- Serena MCP: https://github.com/oraios/serena
- Sequential Thinking MCP: https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking

Where to Find the Hosts
**TJ Pitre**: Founder of South Left, creator of Figma Console MCP, and educator on AI and design systems. Known for bridging the gap between design systems infrastructure and AI-powered workflows. (https://southleft.com/)
**Ben Callahan**: Host of The Question, Founder of Redwoods Design System Community and Founder of Sparkbox. (https://bencallahan.com, https://sparkbox.com)

Get the Raw Data
Access the complete survey data from Episode 068 to conduct your own analysis (https://bit.ly/4apfR5v)

Review the FigJam Notes
Dig into the collaborative notes we took as a community during the deep dive (https://bit.ly/4c9cvFp)

Join the Conversation
The Question explores design systems topics through community research and deep-dive discussions. Visit the show website to participate in future episodes and join the conversation. (https://bit.ly/answerTheQuestion)

Episode 067 Deep Dive: Design Systems That Differentiate

Introduction

Welcome to The Question Episode 067 Deep Dive. Host Ben Callahan is joined by Yesenia Perez-Cruz—author of Expressive Design Systems and former design systems leader at Vox Media and Shopify—for an interactive conversation about design systems that differentiate. This session brings together dozens of design systems practitioners to discuss the tension between sameness and differentiation in our consuming products.

Ben surveyed 1,027 design system practitioners and received 55 responses exploring three key questions: Where does sameness emerge in products? What's your system's primary goal (efficiency, cohesion, or differentiation)? And what bottleneck most restricts product expression? The conversation reveals the cultural, architectural, and philosophical challenges of building systems that both accelerate and differentiate—featuring perspectives from teams across the world.

Show Notes

00:00 - Welcome & Yesenia's Background

• Ben welcomes participants and introduces Yesenia Perez-Cruz as co-host
• Yesenia's journey: Started with graphic design education (primarily print, some early Dreamweaver)
• First job at Happy Cog agency doing responsive websites
• Early realization: Need to make decisions systematically (not 10 different header styles)
• 2011: First article on design systems (describing systematic decision-making process)
• Agency work delivering "style guides" to clients, early theming work
• Jose Garces restaurants project: Six distinct restaurant brands requiring systematic brand expression
• Vox Media: Led design system for eight distinct editorial brands moving to centralized team
• Shopify/Polaris: Led system that had good adoption but noticed sameness creeping in 
  • Point of sale team adopted admin system—felt too similar
  • Mobile team had same issue
  • Focus: How to get diverse expression within huge platform
• Six years at Shopify, now doing independent design work and consulting

03:14 - The Expression Lens: A Different Approach to Systems

• Most practitioners enter systems looking for consistency
• Yesenia's unique lens: Systems can empower/enable expression
• Consistency is good to an extent, but that extent is often exaggerated
• Clear inconsistencies can break trust (example: phishing email from your bank)
• But consistency can delve into a space where "it's not good anymore"
• The problem: Design solutions aren't actually communicating information when content is flattened
• Many challenges stem from pushing too hard toward consistency

04:40 - Survey Results Overview

• Question 1: Where do you notice sameness emerging? 
  • Overall layout and page structure
  • Visual hierarchy and emphasis
  • Interaction patterns and behaviors
  • Brand expression and personality
  • "I don't notice meaningful sameness"
  • Results: Fairly even distribution (30-50% each)
  • Very few people (5-6) said they don't notice sameness
• Follow-up question posted: For those who don't notice sameness, what's unique about your architecture or processes?
• Question 2: Primary goal of your system? 
  • About half: Operational efficiency
  • Others: Brand cohesion
  • Smaller group: Product differentiation
  • Observation: Most teams want both efficiency AND cohesion
  • Forcing choice to primary goal revealed interesting tensions
• Question 3: Open-ended responses about bottlenecks 
  • Component flexibility
  • Token structures
  • Documentation (big theme)
  • Decision paralysis (surprising theme)

09:24 - Decision Paralysis and Designer Safety

• Key insight: Best design work happens when designers are relaxed, having fun, in flow state
• When you don't know the bounds you can work within, you tense up
• "Can I put this line here? Can I use this color background? Will I get in trouble?"
• Result: Retreat to what feels safe—copying what's already approved
• Lack of clarity about permissions takes away the safety of design
• Not about sacrificing brand expression for consistency—need to solve this tension
• Knowing the bounds enables creative problem-solving with the design language

12:13 - Stephen: AI and Design Systems Parallel

• Working with AI recently reveals similar challenges
• AI "does whatever it can to not follow the rules"
• Explores areas where documentation doesn't quite forbid something
• Same question: Where are proper constraints vs. room for creative exploration?
• How do companies prioritize tasks for AI (needing explicit boundaries) vs. humans?
• Yesenia's response: Design language as a tool for creative freedom can be liberating
• Humans have judgment to assess "is this working well?" that AI currently lacks
• Need to meet both ends of the spectrum

14:09 - Kaelig's Comment: "Everything Looking the Same Is Good"

• Chat comment challenges fundamental assumption
• Yesenia's response: There are phases to design systems 
  • Typically start wanting convergence—reducing too much variation
  • This is absolutely valid
  • The problem: How to get convergence without getting stuck in place
• Five years ago problem: If you created a system 5 years ago, you're converging on how the product existed then
• Need ability to move from there
• Expression clarification: Doesn't necessarily mean brand personality 
  • Core question: Does the thing you're using look like the action you're taking?
  • Mac example: Control Center (big affordances for quick actions) vs. System Settings (tiny controls, explanatory text)
  • Spectrum of UI tailored for specific tasks
• Expression is about appropriateness to context and content

16:33 - Matt (New York Times): Typography, Culture, and Letting Go

• NYT designers are very particular about typography
• Previous systems were strict: "text-small, text-medium, text-large"
• Stakeholder requests: "I want 15 [pixels]"
• Matt's evolution: Trying to let go of rigid rules
• Opportunity: When you let go, the culture of the design org can come out
• Tension: Also creates room for chaos
• Question: How do you give up design system control and give control to customers?
• How do teams manage based on org culture?

17:44 - Layers: Tokens, Components, Composition

• Yesenia's framework: Push as far as possible at compositional layer before changing token layer
• Can do something more powerful at composition than at token level
• Promo card example: 
  • Team wants new color token for "promo"
  • Yesenia pushes back: What's more powerful to indicate promotion?
  • Uber Eats reference: Promo card looks like actual coupon—different z-index, inset notches
  • Much stronger visual representation
• Decision criteria: Pus...