Episode 077 Raw Data

Thanks for your interest in The Question!

Sign up to participate in future questions here.

This file is the raw data from Episode 077, deep dive hosted on July 9, 2026 with Ben Callahan and Lauren LoPrete.

There are 61 answers. The question this week was:

-----

Hello, system thinkers!

Last week, Lauren LoPrete and I were talking about control. Specifically, the temptation to reach for it, and what happens when you do. Lauren is early in her tenure leading design foundations at Mercury, but she's navigated the same pressures we all have in her career.

Stakeholders who believe a top-down mandate is the key to adoption…

Engineers who want a design system approval gate before anything goes to production…

Product teams who want the system to give them every piece and part of their interfaces…

We all know these stories. Many of us know they don’t often end well.

Lauren and I are both making a bet on culture over compliance. "My team can build all the tools in the world," she said, "but the tools don’t solve the problems." The cultural solutions are the ones that actually scale. And they don't create the support burden that mandates do because when you force adoption without earning it, you own every problem that follows.

But we know not everyone agrees with this approach.

Relinquishing control means accepting that you can't see everything. It means trusting people you don't manage, in parts of the organization you don't run, to make 1,000 good decisions a day. That's hard to sell. And in a moment when AI tools are shipping UI faster than any team can review, the pull toward gates and guardrails is only getting stronger.

We want to know where your team sits and whether the case for trust is still one you can make.

Welcome to Episode 077 of The Question, with Ben Callahan and Lauren LoPrete!

How much do you believe that culture-change approaches (community, relationships, shared values) outperform compliance approaches (mandates, gates, enforcement) for long-term design system health? (Select one)
• Strongly (culture is the only thing that scales)
• Somewhat (both have a role depending on maturity)
• Not sure (I've seen mandates work when done well)
• I lean toward compliance (without structure, nothing sticks)
• N/A or Other (please explain)

What's the primary mechanism your team uses to drive design system adoption? (Select one)
• Mandates or top-down org pressure
• Tooling and workflow integration (plugins, linters, skills)
• Community and relationship-building
• Incentives (it’s how people are evaluated)
• We don't actively drive adoption, teams opt in
• N/A or Other (please explain)

Who is held accountable for design system adoption within your org? (Select one)
• The design system team
• Product designers and engineers on consuming teams
• Product managers of consuming teams
• No one, it's voluntary
• It's shared, but murky
• N/A or Other (please explain)

Describe a moment when you chose to relinquish control. Tell us what happened.
[open text]

Question 1: How much do you believe that culture-change approaches (community, relationships, shared values) outperform compliance approaches (mandates, gates, enforcement) for long-term design system health? (Select one)

Question 2: What's the primary mechanism your team uses to drive design system adoption? (Select one)

Question 3: Who is held accountable for design system adoption within your org? (Select one)

Question 4: Describe a moment when you chose to relinquish control. Tell us what happened.

Strongly (culture is the only thing that scales)

Community and relationship-building

No one, it's voluntary

We generally always relinquished control on how teams use the system and tried to keep control of what comes into the system. What happened though is that some people from product teams wanted control of what came into the system in order to have the system team developing their components instead of their internal teams without too much care and know-how of what the consequences were for adding a new variant, a new component that only they needed etc.

Strongly (culture is the only thing that scales)

Tooling and workflow integration (plugins, linters, skills)

It's shared, but murky

With some upcoming product launches (Spend and Books), there’s a huge opportunity to raise the craft and build stronger system foundations. But we’re also a new team, and those product teams need to move quickly. We don’t yet have the bandwidth, or the organizational influence, to be deeply involved in every decision.

That means some experiences will be bespoke, some patterns will emerge through experimentation, and some things will inevitably ship without our input. We’ve accepted that tradeoff. Rather than trying to gate every decision, we’re focused on being strong partners: staying close to the work, offering guidance when teams ask for it, keeping visibility into what’s being built, and influencing where we can.

Over time, we’re betting that trust, relationships, and consistent support will have a bigger impact than trying to control every outcome. It also lets us focus our energy where it has the highest leverage instead of stretching ourselves too thin.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

The design system team

I actively campaigned for product teams not to use the spacing system and to deviate from existing patterns when the design system components were limiting them. I made great connections with this approach, and people would then come to me naturally with suggestions or contributions back to the system. This feedback loop wouldn't have existed with a purely compliance-oriented approach.

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

It's shared, but murky

We never had control. It’s an org with dozens of design teams, each with their own product and engineering partners. Adoption is kinda doomed from the start.

Between “strongly” and “somewhat”.

Culture is the foundation from which we all operate; therefore, a weak culture will always produce weak outcomes. But operating also requires teeth that act as signal for meeting the standard of that culture.

You can have a culture of supporting accessibility, but what happens when someone ignores that standard (intentionally or otherwise)? You have to apply mechanisms that enforce that standard.

I certainly lean on the side of culture, but mandates have a place *after* those cultural norms are established.

It requires the right dose of everything. Mandates, community, incentives, and tooling collectively build and reinforce the system.

The carrots must out number the sticks, but the sticks have to at least sting a little.

In past orgs, design systems.

They way it should be: Leadership — who are the least likely to be held accountable for anything these days.

An org’s design system is mirror reflection of what the org values. If alignment and collaboration is optional, so is the design system. Leadership could change that if they wanted to. They ultimately control all the carrots and sticks, and how they’re used.

Design systems aren’t pet projects anymore, and leadership needs to take them seriously.

Therapy 🤣 — and I’m not kidding.

I came to radical acceptance that I can’t make people care or do what I want them to. People act in any way they see fit.

You can provide better design solutions, tools, documentation, anything… but people can always choose to ignore you for their own rationales.

The question (🥁) is: how to we provide and partner with others in a way that teams WANT to leverage what we provide? You mandate the requirements, not the choices.

Strongly (culture is the only thing that scales)

Community and relationship-building

No one, it's voluntary

Somewhat (both have a role depending on maturity)

Incentives (it’s how people are evaluated)

It's shared, but murky

It was like that scene in The Office when people started noticing the plants are dying and Michael's desk toys aren't set up every day because Dwight, who was doing all of that "invisible" work, got a new job at Staples.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

Product managers of consuming teams

N/A

Somewhat (both have a role depending on maturity)

Community and relationship-building

The design system team

I led a program that embedded our design system specialists inside product teams instead of enforcing compliance from a centralized team place.

This reflects the actual model from the Design System Alignment Program: moving from a centralized support model to embedded, inside-out collaboration, with local champions in each vertical rather than a top-down mandate, and adoption, quality and coverage scores climbing as a result.

Rather than gatekeep, we trained local champions to own adoption themselves, joined their reviews as guests, not judges, and let each team keep its own identity. Ownership replaced enforcement.

I lean toward compliance (without structure, nothing sticks)

We don't actively drive adoption, teams opt in

It's shared, but murky

Relinquish control when teams have time pressure to migrate their apps to the Design System from non-interntal apps (like going from a sales force app into an internal app that we need to rebuild). Because this came from a software outside of the organization, there tends to be a large difference in functionality and tons of conflict between teams that want to 1 for 1 migrate their product and the design system.

Somewhat (both have a role depending on maturity)

Community and relationship-building

The design system team

We're actually in talks about how our core should be more and more configurable, less opinionated, and that governance really belongs to the products/platforms. We're in a pivot to prioritize usage/adoption over governance/consistency. We can be a time/problem saving team, vs a governance team.

So, far we're seeing more folks will use our stuff if they can have more flexibility. And, since we serve the whole company, less flexibility does not really serve us or our customers...so we'd leave it to product teams to then focus on how those configurable widgets should be used.

Not sure how this direction will pan out. We get the 2 directives from leadership about supporting developer speed/experience (more configurable) and governance (more control), but they seem to be at odds and not taking into consideration that some other tools or processes may be better at the control portion than the design system. Maybe we really just need to encourage usage of Brand and make building easier, the end.

Somewhat (both have a role depending on maturity)

Community and relationship-building

It's shared, but murky

I set up the basic components of our system, and then I have tried to sit back a little and let people use them and see what gets built. I have a lot of conversations with consuming teams, particularly the designers, and I am building and making updates to the system based on feedback. We want consistency across the app, and I have tried to let the teams build and then go back and document common patterns, instead of making pattern decisions that aren’t going to work in practice. It’s a work in progress.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

The design system team

I don't have enough time and energy to review everything for QA. I set up instructions and am trusting the rest of the process to find issues along the way for my peers when I don't have enough time to do QA. Luckily, right now we're mostly doing reviews of coded components so we're not the starting point of any waterfall decisions without QA.

Somewhat (both have a role depending on maturity)

We don't actively drive adoption, teams opt in

I can't say "design system team" because I'm the only designer here. I'm responsible for both output quality AND establishing the foundations that enable quality.

Me entire tenure at my current company has been a exercise in pushing for better quality while allowing others to jump in and create with me. We use Lovable, and I am frequently given product prototypes to "improve visually". The issue is, I stepped into a company with zero design system/set of standards in place, so I've had to find ways to push for higher standards and quality, while not shooting down the creativity and enthusiasm of other team mates. It's not my place to tell others that they can't have great product ideas simply because they're not designers, but it's also my responsibility to continue pushing for standardization.

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

It's shared, but murky

A team got permission to spin up a new design system just for their part of a project (we had no choice but to give up control). I still don't think it's finished and we have to let them know when DS updates happen so they can try to stay in sync.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

It's shared, but murky

I started by believing the research I had into best practices and guidelines was my job. I've found that the reality was to also interpret the culture of the organization because they will revolt if what I offer doesn't meet their expectations, even if it is what is best for everyone. In this way, I've flipped entirely to allowing the organization to contribute while I highlight where improvements could be made if the culture wants to dedicate resources to do so.

I lean toward compliance (without structure, nothing sticks)

We don't actively drive adoption, teams opt in

No one, it's voluntary

My current system team lacks any sort of control over system adoption or definition of what proper compliance looks like. The result is a lot of hard coded overrides to the system across the entire product. This is not inherently due to a lack of control, but it is a key variable.

Not sure (I've seen mandates work when done well)

The design system team

N/A

I lean toward compliance (without structure, nothing sticks)

Community and relationship-building

It's shared, but murky

N/A

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

Product managers of consuming teams

Not much happened when I relinquished control, just personal peace. It is painful, but I have to accept that people and teams will catch up only when they are ready and thirsty enough.

Somewhat (both have a role depending on maturity)

Not actively working on design systems

There was a clear deviation from a dashboard widget component my DS team had designed and one that was going to be released to prod for a specific product line and instead of telling that team to change their design we decided to let them run it but with the caveat of including analytics that we could use for a sort of A/B test.

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

It's shared, but murky

We chose not to make the design system an approval gate for every product decision. Instead, we focused on making the system more useful: better tokens, better components, clearer documentation, and stronger developer guidance.

The result was better than control. Developers started to trust the system because it helped them ship faster and with more consistency. They became strong ambassadors of the design system, sometimes even helping designers see the quality gap more clearly.

It showed me that relinquishing control does not mean losing quality. It means replacing enforcement with enablement, trust, and better tools.

I lean toward compliance (without structure, nothing sticks)

Community and relationship-building

It's shared, but murky

The "standards" are separate from the "system," but people mostly understand that the system is the easy way to meet the standards. That said, that education is ongoing for sure

Somewhat (both have a role depending on maturity)

Incentives (it’s how people are evaluated)

It's shared, but murky

When expanding the design system team to include interns and associates. There was an impact to quality but we learned to mitigate that with more frequent touchpoints and hands-on reviews. The benefit of adding these fresh-perspective folks to our team has far out-weighed any time put into training.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

It's shared, but murky

There is often a point when determining how flexible to make a component - should we make this a slot? Could it accept any node? - where we have to trust that our consumers won’t do ridiculous things with it. That could be changing with AI as consumers as they may well be more likely to do something unexpected or find a hidden leverage point. So helpful to build in checkpoints, and documentation for anyone and everyone.

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

The design system team

I'm essentially relinquishing control at the handoff phase of every component I ship. To do this, I remain open to feedback from engineers, product designers, and other partners so that I can make space for component improvement through collaboration.

Recently, an engineer wanted to update our Sheet component to support a subtitle in the header. I was tasked with responding to this request in a way that wouldn't turn our design system into a collection of one-off exceptions. I supported the change and quickly updated the design. As I did, I made sure the changes aligned back to our broader system (e.g. standardizing text size and spacing).

Ultimately, the consuming team got a path forward with their use case, and our design system evolved to a real product need. Best of all, the component stayed cohesive because these changes were absorbed into the system's logic and not an ad hoc customization.

Somewhat (both have a role depending on maturity)

Community and relationship-building

No one, it's voluntary

The design system team doesn't have control to relinquish, but we are invited to product teams' design reviews to provide feedback, both from a "governance" perspective and from a design critique perspective. The design maturity across product teams varies somewhat significantly and the design system team has some of the org's most experienced designers, so there are some groups that our designers will work very closely with and others that are very self sufficient. All of it builds a more consistent experience for our customers.

Strongly (culture is the only thing that scales)

We don't actively drive adoption, teams opt in

It's shared, but murky

I don't have a perfect example of me consciously *choosing* to give up control. But in my previous role, I found myself in a situation where our DS team owned the system, while the overall strategy was ultimately driven by leadership.

As a member of the DS team, it didn't feel like I was choosing to let go of control...it felt like I was being told to. That was difficult at first. But over time, it made me a much more strategic designer. Instead of pushing back on every decision (and there were definitely plenty we disagreed with lol), we started thinking about the design system more holistically. We asked ourselves: What are the most fundamental pieces that really matter? Those became the things we fought for, while we let other decisions evolve. We learned to pick our battles.

What made the experience especially interesting was that we weren't just advocating for the design system, we were also advocating for users to have more control. In many organizations, the tension is between the design system and product teams or consumers of the system. In our case, the tension was different. The DS team was balancing leadership's vision while also pushing for the people using our products to have more flexibility and control.

Im a better designer because of this experience. It taught me how to focus on what matters most, influence strategically, and recognize when letting go of one decision creates space to protect the ones that have the biggest impact. It was a hard path to navigate, but I'm glad I went through it.

Somewhat (both have a role depending on maturity)

We don't actively drive adoption, teams opt in

The design system team

Recently had a designer "break" from the system and we had an internal moment of reckoning that we can't complain about a limited brand palette while also constraining the design system. We encouraged the designer to explore the new direction while contemplating systemic use beyond this one task and to come back to us if it ends up being a success.

Somewhat (both have a role depending on maturity)

I think it’s an even split between top down directive and community relationship building.
The bigger or more visible applications are getting top down direction, or at least pressure to do all new builds with the System.
In the flip side we have significantly more smaller and less visible applications using the system due to relationship building and word of mouth

Kinda no one…but if it’s anyone it’s on the design system team to make subscribers happy and want to adopt.

I recognize that I usually feel uncomfortable relinquishing control when I know me or my team will be held accountable for the results.

So recently during support hours, someone asked about detaching a component to make a change. I didn’t flinch at the word detach, like I usually would. Instead, I started by clarifying accountability. I Said detaching a component isn’t against any law, it’s just important to know that if you do, that part of your layout or flow might not get some or all of the future updates we make…so the responsibility will be on you to watch out for changes and update manually, if you want to keep those files current.
Maybe no one really needed me to say that, but it did relieve the anxiety around being accountable for a decision I don’t own. I told them what they wanted to do didn’t explicitly break any higher system rules and so they should do what they thought makes sense for the UX.

That person hasn’t come back complaining that their files aren’t updating consistently, so I take that as a sign it went well?

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

No one, it's voluntary

Though our small, but mighty, team has gone above and beyond to encourage design system adoption by providing comprehensive guidelines, time-saving tooling, helpful tutorials, and a very responsive support channel, we have still not been able to influence all of our products to move past level one (theming) adoption. They always make excuses why they can't (e.g., not enough bandwidth, not in the roadmap, have to complete feature requests from customers first, etc.) and management has yet to mandate it. And so, adoption continues to feel like an uphill battle and that is disheartening.

Strongly (culture is the only thing that scales)

Mandates or top-down org pressure

It's shared, but murky

Strongly (culture is the only thing that scales)

Community and relationship-building

It's shared, but murky

A consumer team for a design system I worked on was once very resistant to using it, driven by a bunch of arbitrary things they didn't like and the strong opinions of a few influential people. Instead of trying to force the team to adopt through top-down pressure, we backed off from direct push and focused on understanding their challenge and building the best possible solutions we could. Over time, the resistant consumer eventually came around when they saw how well the system worked for their needs and how we'd considered their concerns and factored them into our solution.

It was a long game; it took time, but culture change can take time when you're trying to break down and change strongly held opinions (whether right or wrong).

I try to encourage my teams to always assume positive intent; there is a reason someone wants to do something differently. Let's first understand that and use it to our advantage, build the best solution, and make it a no-brainer to adopt the system.

I lean toward compliance (without structure, nothing sticks)

We don't actively drive adoption, teams opt in

Product designers and engineers on consuming teams

Love this topic. In the last year or so, my view on the governance has changed a lot. I think the control I gave up was not the influence, rather intervention. With AI, it's becoming impossible to review every decision made by human or AI agents. Instead, I focus on designing the conditions where good decisions emerge naturally, and encode it in the environment. To me, that's the future of governance. Not governing more, but making governance increasingly unnecessary.

Somewhat (both have a role depending on maturity)

We don't actively drive adoption, teams opt in

It's shared, but murky

When migrating to our new figma component library file, we set a hard deadline for product designers to use the new file but ownership was completely on them. We gave education and support but it was ultimately the product designers' responsibility to consume the new component library and know when to use it or not, and to communicate that when delivering product features to their devs.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

It's shared, but murky

My team launched a component along with a style guide, but left creative control in the hands of the brand marketing team, who were the primary consumers of the component. That decision did not go over well. Quality issues were raised, and product design leadership thought that we (Systems) should have more oversight over what they produce.

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

It's shared, but murky

Most of the design systems I have worked on have not had any sort of adoption mandate from leadership. We tried hard to create a useful tool and offer excellent support and communication to evangelize the system to teams but, in the end, certain teams flatly refused to even test it and continued to build their own versions of components and patterns. We chose to stop trying to fight the situation and to allow them to continue in whatever way they saw fit, recognizing that we might never be able to convince them of the value of adjusting their established workflows to conform.

Somewhat (both have a role depending on maturity)

Tooling and workflow integration (plugins, linters, skills)

No one, it's voluntary

Early days for us, but there are many moments when Eng builds something better new and doesn’t wait for design. So design has learned to let go of those initially, and push for reconsidering the work if it becomes enterprise-relevant (I.e. a prominent client-facing tool/feature)

Somewhat (both have a role depending on maturity)

Community and relationship-building

No one, it's voluntary

both the crm and b2b team have different needs. originally we wanted our (web) components and designs and type styles to work across all, but after talking / interacting w. the teams and seeing their use cases we decided to go with a more hybrid approach that allowed those teams to have more hands on the wheel, while we just guide based on our overarching knowledge of the system.

Somewhat (both have a role depending on maturity)

We already have a design system in place - so changes and amends are the things we focus on.

Product designers and engineers on consuming teams

I realised I didn't need to control every design decision. When developers challenged parts of my design, I let go of trying to protect my solution and instead focused on the product outcome. That shift led to better collaboration and a solution everyone felt ownership of, rather than one that was simply "my design."

Somewhat (both have a role depending on maturity)

Community and relationship-building

The design system team

Over the years we've had a couple teams who could not get on board with using design system components (they were stuck on either their own component libraries or MUI). Eventually these teams have had to come around either because new leadership has come in and been more firm with them, turnover has put new people on the team that are more into the design system, or because they now stand out as the odd teams out among a sea of other teams that are looking consistent due to using the design system. I think it is healthy for the design system team to let the real naysayers go and wait it out, in my experience most end up coming around eventually.

Somewhat (both have a role depending on maturity)

Enabling top-down strategic imperatives that are not directly related to the design system, but can be achieved with greater efficiency through design system adoption.

Adoption is a KPI but not a top down mandate.

We created a sandbox for teams to share UI concepts/ideas. It became a place for us to share feedback and guide teams towards reducing arbitrary uniqueness. Limited engagement so far. We are thinking about how we might scale this further.

I lean toward compliance (without structure, nothing sticks)

Mandates or top-down org pressure

Product designers and engineers on consuming teams

We've had new feature teams setup as 'start-ups', and were given the mandate by leadership to ship as fast as possible without adhering to any standards or our system. It resulting in mountains of tech and design debt, which we still have no cleaned-up to date (over a year ago).

Strongly (culture is the only thing that scales)

Mandates or top-down org pressure

No one, it's voluntary

One of the hardest lessons I learned managing a team is to let go of how something is done.

Everyone has their own paths to accomplishing goals. And letting go is hardest when their approach is vastly different from yours.

Share the goals, restraints, and processes, and then empower others to accomplish it their way. Their path is not going to be your path, but the goals should be met all the same.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

Product designers and engineers on consuming teams

I'm 100% on board with engineering extending components in code; they get all that goodness built in to build on top of. I've seen design leadership struggle more with relinquishing control - "No Detatching!".

I think culture becomes relevant when we need to figure out how, if we allow engineering to extend functionality, or make a system component more complex, what is the equal message to designers when adopting design systems? I think the "how to", or helping designers understand how to extend components in Figma so that they're not diverging (i.e., doing something engineers won't be able to accomplish), but extending or enhancing in a way that scales. That feels like a cultural challenge.

Strongly (culture is the only thing that scales)

Mandates or top-down org pressure

It's shared, but murky

To support a team adopting a new major release of the system they were aided on how to use it but not told they could or couldn’t do certain things by the design system team. The design with some DS components and some custom areas using tokens looked mostly good but the developed output quality was poor. The biggest concern I see is just bad design or development so the output just looks bad so culture needs to maybe include some training or inspiration by internal influencers that are really good or just have smaller, highly skilled teams. Both hard to do in big organizations.

Strongly (culture is the only thing that scales)

Community and relationship-building

It's shared, but murky

We had the CEO mandate design system use, meanwhile the system was still being built and teams wanted all the parts before adopting, so at first it lead to some "malicious compliance". PMs were told to enforce usage, so they would simply lie about it. Shipping takes priority, so the DS team had to let non standard things go through, because there wasn't time to fully spec and document new components. When we let go of some control and had time to build relationships with adopting teams, I wrote processes that were more flexible for building components alongside software (allowing alpha and beta versions of pre-specced components) and for updating and converting existing software.

Strongly (culture is the only thing that scales)

Tooling and workflow integration (plugins, linters, skills)

Product designers and engineers on consuming teams

I have to relinquish control everyday. The developers are moving much faster than we can keep up. However, with great communication we are able to guide the adoption and adaption of the design system to create a UI that still excels what AI could ever be capable of on its own.

There's so much nuance in individuals. Some really respond well to the offer of structure and rules. Some need the strong cultural connection to the 'why.' One of the hardest things about building a system that can work flexibly within rules is realizing the motivations behind using it, or not, are so complex.

Incentives (it’s how people are evaluated)

Product designers and engineers on consuming teams

Every day, we are just one human asking the universe to shift.

Somewhat (both have a role depending on maturity)

Community and relationship-building

It's shared, but murky

relinquishing control can sometimes come down to how a component is implemented. merely deciding to build something as a slot or a property has an effect on loss of control.

if you build it with a slot that can accept any content, then you lose control over what that content will be but you enable the flexibility to invent new use cases while still adopting the component.

likewise if you build the same feature via a property with certain allowed values, you exert your control and achieve some consistency, but the component remains closed to certain types of new use cases.

i call this problem the “flexibility/consistency spectrum” and have talked about it a lot. it is impossible to have both consistency and flexibility. offering flexibility means having less consistency. and have more consistency means having less flexibility. as design system leaders, we face this conundrum every single day with every single component api design choice we make. we need to establish core principles and then use those to make case-by-case decisions to selectively enable or constrain.

for example, color choices might be something we implement css variables that enable flexibility, but accessibility concerns we might constrain such that there is always an accessible label between an input and its label even if the consuming developer doesn’t provide one.

some components end up more flexible because of their nature, like cards, dialogs and accordions where their contents are unknown. others end up more consistent like buttons and icons because they represent the brand more closely.

overall system maintainers should decide overall where they want to land on the flexibility/consistency spectrum and individually where each component will land as well.

Somewhat (both have a role depending on maturity)

Community and relationship-building

No one, it's voluntary

Since our design system is still in its infancy, with very few tokens and components, we've no choice right now but to relinquish control. We advocate for teams to use what's available if it works for them, and give them permission to detach and/or create whatever doesn't. If they do the latter, we encourage them to submit a Feature Request... either formally via our intake form, or informally through our other support channels. Because it's so early and we've yet to devise good metrics-tracking, it's hard to tell yet how this is going.

Somewhat (both have a role depending on maturity)

Accessibility has been a key driver for us. When the system components bake as much accessibility as they can, it helps teams address the top down mandates around accessibility. Adopting our components can sometimes equal or decrease the level of effort for a product team that can simply adopt our component rather than fix the accessibility issues and continue to own that maintenance in the future.

It's shared, but murky

To me, recipes and patterns are a form of relinquishing control. Sometimes the level of flexibility needed warrants this approach but where it gets tricky is how much effort a consuming team needs to exert to get nearly the same thing that the other products want. In some of these cases it makes sense to relinquish control to the product teams but we are still trying to figure out when to componentize some of these patterns in a way that makes certain parts strict but leaves other parts flexible. I believe that every team deserves to have a certain level of control to differentiate their product from others, but there is great utility in accepting other parts of that thing as a standardized and codified approach.

Somewhat (both have a role depending on maturity)

Incentives (it’s how people are evaluated)

No one, it's voluntary

every. dang. day.

in the name of agile and moving fast I have watched multiple teams stand up new products completely outside the system, just to be told, "we will circle back it after launch."

my org has a policy that all digital products must use the system, but no one is enforcing it.

Somewhat (both have a role depending on maturity)

Community and relationship-building

The design system team

Delegating cross-team coordination that others wouldn't let go of-- I formally delegated a cross-team design alignment initiative to one of my senior leads — someone fully capable of owning it. But the partner teams kept routing decisions and meetings back to me, refusing to
include my delegate even after I'd made the handoff explicit.

What happened: The delegation didn't stick because the other parties only recognized my authority, not the person I'd handed it to. I ended up as a shadow owner — still monitoring, still being pulled into meetings, while my lead wasn't getting the access or recognition needed to actually run the work. The cost was double: they weren't empowered, and I wasn't freed up.

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

It's shared, but murky

An existing product team is unable to use our components because it doesn't work smoothly with their framework of choice. So, instead, they chose to directly use design tokens in their CSS. While components offer compliance as a package, using tokens is a step towards greater compliance, so we worked with them to figure out a path that works for their team

Somewhat (both have a role depending on maturity)

Mandates or top-down org pressure

It's shared, but murky

I led the Design System initiative by bringing together members from both the Design and Engineering teams who have DS experience and interest. When we went through a re-org, there were a lot of changes to department and team structures. I went from leading the DS initiative to being an IC on the DS Eng side and my new team (led by an Eng Manager) being the overall owner of the Design System. This led to some of the DS direction changing but I'm good with it since the DS awareness and adoption is increasing and that is the big picture goal.

Strongly (culture is the only thing that scales)

Community and relationship-building

The design system team

We are in a government context. We are a more flexible and modern solution to a legacy design system. Because teams aren't required to use our design system (they don't have to migrate yet), we don't govern through mandates, and we focus on earning adption. We invested in documentation, research, community forums, a contribution model and partner relationships. We aim to provide the guidance, tools, and support they need to make good decisions.

I can see that some of our users are used to a more prescriptive approach, but I also see that they appreciate our flexibility and transparency. I'm not entirely sure yet of the outcome, but I think relinquishing control helps us build stronger trust, because our users know they have an opportunity to contribute code, use cases, research, designs, bug reports, etc.

Strongly (culture is the only thing that scales)

Community and relationship-building

Product designers and engineers on consuming teams

From an accessibility partner pov, we have to relinquish control all the time depending on design and development inclusive maturity, and building relationships. We compromise on inclusive solutions, esp. in app accessibility, because WCAG does not cover app as clearly as it does for web. To "relinquish control" and still provide guidance, I use Must/Should/Could framework for communicating accessibility requirements that keep the business safe (must) vs. ways we can exceed WCAG/EAA/and other international a11y compliance laws for a better user experience that is backed by strong recommendations from accessibility expertise, user research with disabled participants, following platform design system (HIG & M.3), in addition to legal requirements/criteria (should/could). Breaking down guidance using this framework provides multiple paths forward for designers to choose but will still minimally be in compliance, it levels up inclusive design knowledge and builds trusts in accessibility partners.

Somewhat (both have a role depending on maturity)

It used to be education from DS designers to product designers and using the design team to drive adoption through the design process. Lately we've been trying to lean more into tooling and workflow integration with linters and skills.

The design system team

In general we relinquish control on the DS team when a team chooses to build something custom. We provide as much shared component and guidelines across figma and code as possible, but rely on teams to build custom solutions when they need. This allows us to test new interactions that have new use cases without needing to pivot on our existing priorities.

Somewhat (both have a role depending on maturity)

We are mostly opt-in but try to integrate adoption into the way we build and roll out components

The design system team

I'm intentionally rebuilding components with a 2 layer API: off the shelf prebakes that cover common cases built on a second layer of configurable knobs that are a bit hard to use, but still available under the hood.

Haven't gathered much data yet but the impression I'm getting is these components feel more advanced and useful than the strict components I inherited. Nothing has exploded

Somewhat (both have a role depending on maturity)

Community and relationship-building

Product designers and engineers on consuming teams

At Dictionary.com, I decided to stop screaming about the virtues of design system. Instead, my team and I focused on improving workflow, delivery speed, and debt reduction—all shared Design and Engineering goals. We used design system as a way to accomplish that and soon found that Engineering became equal partners in design system and our CEO became fluent ion the concept. Our design team made a point to celebrate our engineering team and the impact of our lean-forward collaboration.

100