Live recording of the fortnightly podcast Design Systems WTF (back for season two!), where Luke Murphy and Michelle Chin attempt to combat all the amazing wtf in design systems. In each episode, they answer a single question around design system troubles with a Q&A from the live audience.

Time to get spicy... One of the big promises of the hype of design systems was that it would reduce organizational and product complexity by providing efficient, replicable ways of doing things. Now that we've bedded in, its time to ask - how much do design systems actually reduce complexity? Do they just reorganize and make complexity more palatable?

Show notes

• Product Deep Dive on Systematizing your Documentation
• Michelle’s article on structuring your design systems

Live recording of the fortnightly podcast Design Systems WTF (back for season two!), where Luke Murphy and Michelle Chin attempt to combat all the amazing wtf in design systems. In each episode, they answer a single question around design system troubles with a Q&A from the live audience.

A bit of a deep topic this week – how important is consistency as a concept to be aiming for with design systems? Obviously, it's one of our design systems' selling points, but in a world where we're moving more and more towards browserless, how important is component consistency, or can we see a place where foundational consistency is all we need?

Show notes

• A List Apart - Design Dialects: Breaking the rules, not the system
• Vinted - Greenhouse

Season 2 Episode 1

Design Systems WTF is the fortnightly podcast where Luke Murphy and Michelle Chin attempt to combat all the amazing wtf in design systems. In each episode, they answer a single question around design system troubles with Q&A from the live audience.

We took a few months off and y'all went and changed everything... We dive into the wonderful world of contextual design systems. Do MCPs finally offer what we need to make our design systems serve information up contextually? Are there major things we need to refactor? Or is it all smoke and mirrors?

Show notes: 

• Knowledge graphs article from Chase
• Luke’s talk on Contextual Documentation
• Converge videos
• DS Live with TJ Pitre
• TJ Pitre on LinkedIn

Selling the value of your design system to folks who don't necessarily understand it is a difficult and thankless task. But are we trying to sell in the right things? Is it possible to put the value of our design system against the bottom line, and how far down the stack can we go? Can we actually put a dollar sign against a single component?

The age old question – should designers know how to code? Or more specifically, how much should designer know when it comes to code? Considering it's the medium that we're designing for, it's still surprising how much this topic splits opinion. Luke and special guest Rob Whitfield will dive into the pros and cons, and give some practical advice if you did want to delve into the witchcraft that engineers do.

Making your design system as inclusive as possible is something that I think we all agree on. However, for most systems teams, this means creating some accessibility guidelines and then ticking it off the list. Is this enough? Is there more we can be doing?

Inspired by Luke's article on the death of design systems, Michelle and Luke dive into whether design systems have a future... are we at a natural point of evolution or are design systems going to go the way of the dinosaurs?

How big is too big? Is there a point where your design system just becomes unwieldy? Luke and Michelle dive into this question from a previous episode, and try and figure out how you keep your design system to a manageable size. Or is that just a nice problem to have, and we should embracing our systems to grow to the size they need to be?

Detach instance is a concept that has stuck fear into the hearts of design systems folks since the beginning. However, there are definitely instances where it’s totally ok to snowflake components! How should you deal with snowflakes in your system? How does this play into your overall view on flexibility, and can you actually use snowflakes as a way to determine what you should be working on?

Sometimes we may feel the urge to include everything in our documentation, to the point where it rivals Lord of the Rings for length and density. However, we may be doing ourselves a disservice! How much is too much documentation? How much is not enough documentation? Do we even need documentation at all? join us for the last Design Systems WTF of the year!