Davy talks special co-host, Guy Segal, about his first month at his new design systems job at Atlassian, and the fun of being a newbie after the first 30 days, when the going really starts getting tough.
Davy and PJ talk about the role of our designers on the ground, we call them our ambassadors. These good eggs not only inform our day-to-day product improvements, but help keep up informed across the org.
Davy with friend of the program, Chela Giraldo talk about their recent experiences looking for a new design systems, and the struggles with developing the "design system portfolio" that can tell our unique stories.Chela has a recent post about it, which you should check out on Design System Collective.
Davy and PJ discuss the challenges and strategies for design system training, especially when it comes to Figma. We explore the line between providing direct tool training and focusing on how the design system integrates with those tools.
Davy talks about what he's seen with the popularity around (local) product systems and how you can may want to adoption via providing just some design system team support. PJ ends the convo with the lighter weight approach of supporting templates in code and design.
Another takeaway from our cross-functional discussions, how do design system team members handle disagreements with consumers, or even our own teammates?
Davy and PJ talk dive into designers building helpers and plugins to support more specialized design system maintainer workflows, and the beauty of unblocking ourselves.
Davy and PJ talk about how to plan to best support inbound product design work, in addition to the differences between product-led work vs design system team-led initiatives.
Because it was PJ's first Config, we decided to record a live, IRL episode, recap our first thoughts about the new product releases and a thread that we started about who Figma is designing for, dating back from last year's event.
We're back with an episode an episode about component and design system flexibility. How opinionated should your design system be, vs a large set of reusable pieces that can be put in any which way together. Davy and PJ weigh in on both methods and where you may want to dive into a framework that allows you to build starting from anywhere.
Our friend Guy Segal, Director of Design Systems at Thomson Reuters comes and talks with us about consistency in operations and how to scale out systems thinking.
We learn about PJ's start in design systems, dating back to 2011, and Davy's first introduction to it in 2015. They discuss while tech has evolved, aspects such as theming still remain a struggle to figure out. Also discussed is how we evolved our roles, and what might be suitable traits and tactics used by design system people in 2025.
Davy and PJ talk about design and code parity, how we keep our artifacts aligned with live product, and other nuances to maintaining large scale component libraries.
Davy and PJ talk about the challenges of updating legacy components from yesteryear, and what it takes to migrate legacy code to new design system components. When is the suitable time to do this work?
Davy and PJ talk about the concepts presented in Brad Frost's 2013 book, Atomic Design, and how a simpler format in present day with components, patterns, and screens may be common representation for design teams.
In our second recent episode about reviewing work, Davy and PJ talk about how we review output from product designers on our teams and the need to stay plugged in so we can help designers earlier in the process.
While the podcast is one form of communication, on our teams we heavily utilize async written communication methods to best spread the good work of design systems. We talk about the different methods we communicate to stakeholders and consumers of our design system artifacts, specifically, documentation.
Davy and PJ dive into the various ways we've utilized crits on our teams to both do design ops related work, but also reviewing code, in addition to design.
Topical for the time of year, Davy gets PJ to spill some beans on how to best set up designers to best prove the value of their day-to-day work in design systems.
While we touched on teams of one, which is quite common in our community, how do we function in medium size teams of 3+ designers, and how can we effectively, and intentionally scale.