How design systems offer creative safety for product teams
Before you read any further, answer one question, quietly to yourself:
Does your design system create “sameness” in the products that have adopted it?
Now, I want you to think about the feeling that question generated in you. Did you feel any defensiveness creep in?
The question itself doesn’t assume a right or wrong answer. Some of you reading this will assume the ideal answer is “yes” and some will assume the opposite. We’ve been chasing “consistency” or “cohesion” in our product design for a long time. Back in 2000, Jakob Nielsen wrote,
“…users prefer your site to work the same way as all the other sites they already know…”
in End of Web Design. This has become known as Jakob’s Law. This makes so much sense and I suspect the system thinkers out there are nodding their heads reading that quote. I know I did for a long time.
Defining the terms
But what is sameness and what is differentiation?
My co-host for Episode 067 of The Question was Yesenia Perez-Cruz. She wrote Expressive Design Systems and she’s spent the last decade helping product design teams figure out how to answer one of the hardest questions in design systems: when to standardize and when to innovate. In our deep dive for this episode, we defined these terms. Here’s a paraphrase of how Yesenia responded when I asked her to help us understand:
There are places in an interface where we need that cohesion—where things that are the same look and feel the same. But an unhealthy sameness happens when things that are different look the same. This is the sameness we need to avoid and the one that many design system teams overlook in the name of consistency. When we’re able to rid our products of that kind of unhealthy sameness, we have differentiation. Finally, there are places where things that are the same look different. This is drift and is where design systems can be especially effective in creating a cohesive product experience. Reigning in that drift leads to healthy cohesion.
I know, that’s a lot of words. Here’s the summary:
- Cohesion is when things that are the same look and feel the same.
- Drift happens when things that are the same look and feel different.
- Differentiation is when things that are different look and feel different
- Sameness happens when things that are different look and feel the same.
With clarity in what we mean here, it’s time to rethink our goals. We want cohesion, not sameness. We want differentiation, not drift.
Why clarity matters
Most of our organizations haven’t clearly defined these words. We use them all the time in north star statements, in our principles or values. We claim the design system is the path an organization must follow to achieve consistency or cohesion in our product interfaces. However, without that clarity, you leave product designers and developers to determine where the line is between standardization and innovation.
There are a lot of reasons to be explicit about what we mean with these words.
More productive critique It’s really frustrating to be critiqued when the expectations for your work are not clear. It’s like losing a game when you didn’t know the rules. Clear definitions and expectations remove vague concerns like, “this feels off-brand” and allow teams to have meaningful conversation about the intention of design or eng decisions.
Accountability for decisions Clearly defined terms serve as a kind of framework that helps teams to justify their decisions. This removes the need for design system teams to establish a posture of authority and allows them to position themselves as enablers of good choices. With this kind of clarity, we can have meaningful discourse about why we’ve made the choices we have!
Reduced institutional knowledge If we rely on individuals figuring out what we mean by these kinds of words through experiences in the work, we’re acknowledging that it’s ok for individuals to own this kind of knowledge in their heads instead of in documentation. Having things defined distributes the ability for everyone to make healthy choices rather than just the team members who have been employed the longest. A side effect of this is faster onboarding and a more scalable culture.
Better tooling and automation When these concepts are well-defined, it becomes possible to build up tooling around them. Linting rules, design tokens, visual regression testing—all of these things can encode the intent of these kinds of decisions right into our tooling. But only if we have taking the time to align on their meaning.
These are compelling reasons to take the time to define these words. But I think there’s one more reason that is critical—the safety of product teams.
Creative safety
During the deep dive, Yesenia remembered back to the times when she did her best design work. It was when she had clarity about what was allowed and what wasn’t. It was when she understood the constraints.
As we unpacked this further, it became clear that the end result of all of the great reasons above to be more clear—more productive critique, accountability for decisions, reduced institutional knowledge, better tooling and automation—is creative safety for product teams.
Creative safety is the confidence to explore, experiment, and challenge design and engineering decisions.
It’s established on a foundation of psychological safety by clearly articulating and applying the boundaries, principles, and processes documented by a healthy design system program.
Creative safety allows you to be bold without creating chaos. It is the knowledge that your ideas will be assessed against shared standards rather than personal preferences or hidden institutional knowledge.
Creative safety replaces anxiety with clarity. It is the understanding that trying a new approach won’t result in me derailing the system being shut down for reasons I don’t understand.
Creative safety enables productive conflict. It allows teams to make their case from a shared understanding and foundation.
Creating creative safety is a massive responsibility for a design system program, and it’s one that we almost never talk about. The result is that many design system teams evolve toward a defensive posture.
Defensive posture
I organized an event in Pittsburgh last year called Symmetry. During a break, I was chatting with a design system consumer who was attending the event. We were talking about design system office hours, where anyone can drop in and chat with a few folks from the design system team. It’s a place where consumers can get some help, ask a question, or offer feedback. When I asked this person if they attend the office hours that their design system team hosted, here’s what they said:
“No. They don’t really listen. They are there to defend the system, not to hear how it could be better.”
A slide from one of my presentations featuring a pencil sketch of a medieval castle fortress on the right side. The quote reads: No. They don't really listen. They are there to defend the system, not hear how it could be better. The word defend is emphasized in bold. Attribution reads DS Subscriber in italics. The castle illustration reinforces the metaphor of defensive gatekeeping in design system work.
That conversation really hit me. It has stuck with me for over a year. We build our walls so high, and we do so with good intent—we’re defending the standard of excellence.
But nothing will shut down creative safety like a defensive posture.
If you want product teams to do their best work, you have to let them. My experience is that your time is much better spent articulating the definitions, principles, boundaries, expectations, and ways of working than defending your system. There will be times when pushing back is necessary, when a designer or developer has taken too much liberty. If you’ve not demonstrated a collaborative, non-defensive posture in the past, you won’t have earned the right to push back. And, having alignment on the expectations and definitions will be the healthiest way to gently reign in drift or push for differentiation.
Design system programs that prohibit expression are doomed to fall out of relevance. If you want to create a sustainable program, you have to start by defining your expectations and removing your defensive posture.
On Thursday, January 29 of 2026 we held the Episode 067 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.
Ben Callahan and Yesenia Perez-Cruz co-hosted Episode 067 of The Question on design systems that differentiate.
Thank you
Many thanks to all who participated.
If you missed out this week, sign up for The Question and be ready to answer next time.
Resources Mentioned
- Yesenia Perez-Cruz’s book: Expressive Design Systems
- Yesenia’s article, Beyond the Plateau of Sameness
- Brett Victor’s article, Magic Ink
- Jacob’s Law on UX familiarity
- Shopify’s Polaris design system
Where to Find the Hosts
- Yesenia Perez-Cruz: Author, designer, and design systems expert known for her work on expressive design and reducing sameness in product interfaces
- Ben Callahan: Host of The Question, Founder of Redwoods Design System Community and Founder of Sparkbox.
Get the Episode 067 Resources
- Access the complete survey data from Episode 067 to conduct your own analysis
- Dig into the collaborative notes we took as a community during the deep dive
- Watch the Deep Dive on YouTube
- Watch the Recap on YouTube
- Listen to the Deep Dive Podcast Episode
- Listen to the Recap Podcast Episode
- Subscribe to The Question Podcast
- Subscribe to The Question YouTube channel
Join the Conversation
The Question explores design systems topics through community research and deep-dive discussions. Visit the show website to see past episodes, participate in future episodes, and join the conversation.
Writing Design Systems The Question Featured
Join Redwoods, a design system community.
Sign up for The Question, a weekly design system deep dive.
Explore more of my writing and speaking.
Or, inquire about design system coaching
