Recap: Episode 067 of The Question with Ben Callahan & Yesenia Perez-Cruz on Design Systems that Differentiate

Episode 067 Recap: Design Systems That Differentiate with Ben Callahan and Yesenia Perez-Cruz

Introduction

Welcome to The Question Episode 067 Recap. In this episode, Ben Callahan sits down with Yesenia Perez-Cruz—author of Expressive Design Systems and design system consultant, to unpack the results from this week's survey on design systems that differentiate.

Ben sent the three-question survey to 1,027 design system practitioners and received 55 responses. The questions explored where sameness emerges in products, what design system teams prioritize as their primary system goal (operational efficiency vs. brand cohesion vs. product differentiation), and what aspect of their design system acts as the biggest bottleneck to product expression. The conversation that follows is a recap of the deep dive into the tension between standardization and innovation, revealing frameworks and strategies for creating design systems that both accelerate and differentiate.

---

Show Notes

00:00 - Introduction & Survey Overview

• Ben welcomes Yesenia Perez-Cruz as co-host for the Episode 067 recap
• Context: Just finished deep dive with participants reviewing raw data
• Survey details: 1,027 practitioners contacted, 55 responses received
• Three questions explored: where sameness emerges, primary system goals, and bottlenecks to expression
• First question results were evenly split across categories (30-50% for each option)

02:27 - Defining Sameness, Differentiation, and Expression

• Participants immediately questioned: "Don't we want sameness?
• Expression defined: Does the interface look like the thing users are doing? Do visual cues communicate content meaning (shipping profiles, order lists, etc.)?
• Sameness defined: When the shape of components overrides the content—everything looks like generic headers, lists, and footers
• The key distinction: Good expression means content emerges rather than being hidden by component structure
• Expression is really just good visual communication and design

04:42 - Did Design Systems Create Sameness?

• Historical context: Brett Victor's "Magic Ink" article from 2005 identified this problem before design systems existed
• Victor argued product designers aligned with industrial design (mechanical tools) vs. graphic design (information shaping)
• He cited "ancestors of design systems" as contributors to sameness
• Conclusion: Design systems aren't the only cause, but are "the cost of economies of efficiency"
• The problem predates design systems but has been accelerated by them

06:50 - Drift vs. Differentiation: Critical Distinctions

• Drift: When things that are the same look different (unintentional inconsistency)
  • Example: Delete actions using different icons (X vs. trash can)
  • Users shouldn't have to relearn patterns for the same action
• Differentiation: When things that are different look appropriately different
  • Things should look like what they are, not all the same
• Sameness: The opposite of drift—when things that are different look the same
• Differentiation serves both interface clarity AND market positioning

08:10 - Brand Differentiation Through Primitive Components

• Two meanings of differentiation: interface clarity and market positioning
• MyMind example: Bookmarking tool with atmospheric, circular branding
  • Reimagined drop zone with circular shapes and soothing animations
  • Standard components (drop zone, color picker) styled to brand essence
• Many teams start by referencing other design systems or galleries
• Key insight: For core parts of your experience, create distinct patterns that feel specific to your product

10:37 - Balancing Usability and Expression

• The usability concern: Familiarity breeds instinctual understanding
• Jacob's Law: Users prefer patterns they're familiar with from other sites
• The nuance: There's space for differentiation in domain-specific components
• When components are specific to your domain (not just functional), users are more willing to learn something different
• The line between standardization and innovation isn't the same for every organization

12:22 - How to Decide Where to Standardize vs. Innovate

• First: Understand the role the system plays in your organization
  • Are you in efficiency mode or innovation mode?
  • This can ebb and flow within the same company
• Second: Understand who needs to create expression and where
  • Example: Polaris serves both third-party developers (who want decisions made) and internal designers (creating new products)
• Different audiences within the same organization may need different approaches
• The person making the choice matters as much as what the choice is

14:35 - Enablement, Safety, and Experimentation

• Design systems shape the culture of how designers work
• The trust paradox: Sometimes teams trust the system too much
• Yesenia's experience: Encouraging teams to "start with a blank canvas"
• Goal was to encourage feedback loops of new patterns into the system
• Creating psychological safety for designers to explore outside constraints
• How the system team responds to requests shapes whether people feel safe to experiment

17:27 - The Blank Canvas Approach

• The risk: Standardizing too much, too early
• Yesenia's system worked well for building 2016's product, but not for 2020's needs
• Strategy: Encourage divergence first, then converge on new patterns
• Can't standardize things that don't exist yet
• Teams sometimes jump to defining palettes and typography before understanding the product
• Creative exploration should continue throughout the adoption process, not just at the beginning

19:10 - Seasons of Innovation and Standardization

• Organizations pendulum between differentiation/innovation and standardization
• Both don't run full steam simultaneously—it's a seasonal shift
• External factors impact business needs, which impact design approach, which impacts what gets standardized
• Example timeline: Knew token layer wasn't ready, encouraged divergence to learn what needed standardizing, then created new token architecture and consolidated
• This required thinking 3+ years in advance
• Design systems practitioners must predict the future (another skill to add to the matrix!)

20:42 - Trust, Responsibility, and Where to Draw the Line

• One participant's perspective: "I don't tell designers what to do, I trust they know their craft"
• The challenge: What does trust mean for design debt and tech debt?
• It's difficult for system practitioners to block product designers' work
• Pro...