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.
In our second episode dedicated to accessibility in design systems, Davy and PJ talk about the surface level explorations of color contrast, then learning more about how to better design for screen readers, for a better web experience.
We start our series with learning about how design systems interact and help our other team members from different disciplines. We start with Matt Petitt, Engineering Manager at Dayforce.
Davy and PJ talk in depth about the perils of chasing efficiency, and how we approach measuring effort and time-saved. And does this tie into velocity at all?
In the tough market of design team contractions, Davy and PJ talk about how to maintain focus and stability as a horizontal design practice.
On this episode, PJ talks about his time using Figma's REST API and how with so much data collected, we just need it to do a little more for us.
These have become some of our favorites, and tend to cover more ground than a typical ep. Nico, community manager for Zeplin joins as a co-host for this special ep.
Happy episode 60! Davy and PJ talk about a popular design system topic when we start out, Contributions and Federated Help. While this all sounds good, what are some of the pitfalls of relying too heavily on contributions and help from external design resources.
Is system adoption the only measure of success? Davy and PJ talk about adoption metrics we tend to tie ourselves to, and how it may not always paint the most complete picture.
Or aptly named, Color Complexity in Design by our GPT pal, Davy and PJ discuss the use or rather overuse of color in product design. When thinking about color in design systems, once again, less is most appropriate.
