bybrandonbrown Design Systems succeed and fail on trust. People need to, at the very minimum, accept and use the tools and processes your design system establishes. Working in design systems is always a balance, keeping productivity high while nurturing trust. One of the most common ways teams try to strike that balance is by giving their community a seat at the table through a contribution model. But contribution models aren’t always the shortcut to trust they appear to be.
You’ve probably done this with your design system, a call for outside contributions. That’s fantastic. Getting uneasy contributors involved is one of the best ways to spark that aha moment and begin shifting them from friction to advocacy.
But are you relying only on those signals from your community to initiate new work? Have submissions piled up while priorities shifted, leaders changed, or core work pushed contributions to the back burner?
Your contribution pipeline has gone stagnant. People start saying things like, “I added this to the pipeline last year - and nothing happened.”
Now your system and team are known for delays instead of decisions.
The Timing Problem with Contribution Pipelines
On paper, a community contribution workflow sounds empowering. A polished component, built in your favorite design tool, and proven valuable in someone’s product is handed to the design system team.
That sounds amazing, but then comes scale.
Designing at scale requires a different perspective than product teams usually need. Product designers should focus on solving specific problems for their users, from the design system perspective I want them always thinking of their users and needs first. But that focus doesn’t always leave room to account for edge cases, cross-platform consistency, or long-term sustainability scaled across an entire organization.
So what happens? A designer submits a hyper-specific, approved component for inclusion in the design system. And then… nothing.
Why should other teams adopt it? Is it stable? Does it solve their needs too? Will it be replaced in a few months by the system’s “official” version already in the pipeline?
A contribution pipeline focused purely on submissions is doomed from the start. On paper, it looks incredible. In reality, the timing is all wrong.
What Is The Next Right Thing?
This is the core of design system work: how do you give confidence to your team, your consumers, and your stakeholders that the system is moving in the right direction, and at the right pace?
Every workplace has inputs: support tickets, community contributions, office hours, maybe even research if you’re lucky. Each of these carries a different weight depending on your company culture but here’s the question: what signals are you missing?
There’s a gold mine of information hiding in plain sight: design reviews, approvals, planning conversations. For some reason, design system teams often struggle to access these, even though they’re the richest source of signals in the organization.
The best design system people I’ve worked with are pattern spotters. They connect disparate efforts, notice recurring needs, and recognize when even a small centralization can create outsized value. That skill seems to be the common thread which makes these stand-out practitioners both successful and excited for the work.
Find these people on your team. Put them to work spying on your organization’s design efforts.
Signal Gathering with SPYING
Contribution pipelines often fail because they’re too passive. By definition, they wait for submissions and then wait even longer while other teams’ backlogs prove out refinement and adoption before the design system team even decides to take action. That can push the system team’s work out for months, even years, leaving contributors frustrated. What design systems need instead is an active, intentional network that surfaces information, insights, and early signals to guide decision makers.
There is a way for design systems to stay ahead of submissions and aligned with the real-time needs of product teams instead of always playing catch-up. Think of it as SPYING. A disciplined practice of listening, connecting, and guiding through an active design-intelligence network.
This means tuning into Signals, extending your reach through Partners, showing up as You, refining those inputs into Intelligence, Navigating the tensions that arise, and providing Guidance that aligns the organization. It’s not about secrecy, it’s about discipline, and about earning trust by being deliberate in how your system gathers information and acts on it.
S: Signals
Contribution pipelines leave you waiting for someone to submit a polished component long after the real decision has already been made. By then, you’re reacting, not guiding.
Signals shift your team into an intelligence-gathering mindset. They’re not about spying on individuals, not at all! They’re about tuning into the moments where decisions are already happening. This could mean:
-
Joining design reviews where patterns get approved or challenged.
-
Sitting in on planning sessions where new work is scoped.
-
Watching codebases to see what’s being re-invented.
-
Building relationships with those who hold approval rights, so even if you’re not in the room, you hear what’s being decided.
The key is this: signals from decision points are the strongest indicators of where the design system should pay attention. They tell you what’s being accepted as the “correct” direction, often before it ever gets submitted as a contribution.
Signals are your early-warning system. Instead of waiting for a backlog submission that arrives months late, you’re aware of patterns at the moment they’re endorsed — giving you a head start in validating, scaling, or guiding them.
What other moments in time, asset creation, or process indicators can you lock onto as a strong signal to listen to inside of your organization?
P: Partners
You can’t catch every signal yourself. Design reviews, planning sessions, codebases, and product conversations are happening all the time across your organization. That’s why you need partners, people who extend your reach and bring signals to you. In reality, you can’t be in all of these meetings and your boss may take some convincing that you need to be in them.
Partners aren’t just contributors, they’re allies! They’re the designers, engineers, researchers, and product leads who:
-
Surface patterns you would otherwise miss
-
Share context from meetings you can’t attend
-
Validate whether a signal is isolated or part of a broader trend
-
Help amplify awareness of design system priorities inside their own teams
-
Will at least give you a “hey have you seen this team doing this” every once and a while
Be intentional in how you recruit your spy network of partners. Don’t wait for volunteers, identify the people who are already trusted within their teams and show curiosity about system-level problems. They’re the ones most likely to thrive as design system partners.
When you invest in these relationships, your intelligence network becomes broader and more resilient. You’re no longer reliant on the single contribution pipeline. Instead, you have a distributed set of eyes and ears helping you spot what matters and where design efforts may be shifting.
So ask yourself: who in your organization is already pattern-spotting, connecting dots, or amplifying decisions? How might you recruit them as partners in your design system network?
Y: You
A design system isn’t powered by tools or components. It’s powered by people. You are at the center of the network, and trust is built (or broken) in how you show up.
For those working on the design system, You means putting people first. Your presence matters:
-
Be visible in planning sessions and reviews, not just in documentation after the fact.
-
Follow through on conversations so colleagues see that the system responds, even if the answer is “not now.”
-
Build relationships intentionally. Credibility is earned one interaction at a time.
But You isn’t just about the system team. It also extends to the people using the system day-to-day. For a design system to work you, the consumer, have to be engaged as well:
-
Share what you’re seeing on the front lines of design.
-
Surface friction points before they pattern into workarounds.
-
Stay open to collaboration so the system team can guide, scale, and support you more effectively.
In other words, You is reciprocal. The system team can’t build trust in isolation, and consumers can’t expect their needs to be met without participation. A design system thrives when both sides lean in. In this arena, leaning in looks like when you contribute presence, trust, and openness to the network.
How are you showing up to strengthen the trust that makes the system and its network effective?
I: Intelligence
Signals are valuable, but on their own they’re just noise. A request here, a pattern spotted there, a comment in a review. Individually, they don’t tell you much. Intelligence is the discipline of connecting and synthesizing those signals into something meaningful your system can act on.
Intelligence isn’t about collecting more- it’s about sharpening focus. A single team’s request may be an outlier, a data point to consider. However, when multiple teams are solving the same problem in different ways, that’s not noise, that’s a pattern worth system-level attention. Many times, teams will talk about work differently, they may not even mention certain aspects of the work that may be a pattern worth your system’s attention. This is where your intelligence gathering and refinement strategies will shine.
Research habits and skill-sets can help. Store notes, submissions, and observations in a way that makes them easy to revisit whether that’s a tracker, tagged documents, or even a lightweight database. Group them by theme, capture the context around each, and review them over time. A researcher would tell you that no single observation stands alone- it’s only by aggregating and comparing that patterns emerge. Apply the same mindset to your design system. Treat signals as qualitative data, and intelligence as the insight you surface when you step back and connect the dots.
This is where the design system shifts from reactive to proactive. By refining signals into intelligence, you anticipate problems before they spread and identify opportunities before they’re requested. Intelligence transforms the team’s role from passive responder to active participant.
The payoff is clarity. Intelligence turns raw inputs into insights, helping the system decide where to act, what to defer, and how to prioritize. Without intelligence, you’re stuck in an endless queue of submissions. With it, you gain a directional map of where your system can create the most impact.
In your work today, are you just collecting signals, or are you producing intelligence that gives your system a clearer path forward?
N: Navigate
“Navigate ambiguity” shows up in nearly every design system job description (okay, most tech/design oriented job descriptions), but what does it actually mean?
In practice, design systems live in ambiguity as they sit between teams, priorities, and stakeholders. Requests often conflict, signals don’t always agree, and the “right” answer is rarely obvious. For something that’s been around now for the better part of a decade, we sure have to remind people far too often what it is we’re doing.
That ambiguity isn’t just in the work, it’s also in where design system teams sit inside the business. Some will report into product, others into design, engineering, brand, or platform. Sometimes they don’t even share a business unit with the teams they’re meant to serve. This shifting context means decision-makers, priorities, and measures of success vary widely, leaving system teams to steer through misaligned expectations and usually leaving a meeting where one stakeholder’s needs aren’t met - or someone is confused again.
These tensions can paralyze a passive system. This framework leans into navigation to gather input from signals and relies on partners to reveal perspectives that would otherwise be missed. By connecting those threads, the system team can see the larger picture and use principles as a compass to chart direction.
Navigation doesn’t erase ambiguity, at best it makes it manageable. By bringing signals and partners into the conversation, mapping the tensions they surface, and being transparent about the trade-offs, the design system builds momentum and maintains trust. Teams don’t expect you to resolve every conflict. They expect you to synthesize the noise into clarity, provide principled momentum, and keep the organization moving.
G: Guidance
Intelligence is useless without action. A design system can gather signals, build partnerships, refine inputs into intelligence, and navigate ambiguity, but if it doesn’t provide clear guidance, teams are left guessing. When people have to guess, they are more likely to lose trust in the system.
Guidance is about turning intelligence into visible, actionable direction. This isn’t just documentation, though documentation plays a role. It’s about communicating why decisions are made, how trade-offs were weighed, and what teams should do next. Guidance is the bridge between intelligence gathering and organizational alignment.
For the design system team, guidance means showing your work. Share decisions transparently, even if they’re provisional. Make the rationale behind patterns explicit so others can learn from it. And when you say “not now,” explain the context so contributors know their signal wasn’t ignored.
Guidance also empowers teams to act with confidence. Clear standards, living documentation, and timely updates give product teams the confidence to move quickly without second-guessing. The more they can anticipate the system’s decisions, the more trust they place in it.
The payoff is this: guidance turns ambiguity into alignment. It’s how a system shifts from passively collecting input to actively steering the organization. Without guidance, a design system is just another inbox. With it, the system becomes a trusted voice in decision-making.
So ask yourself, is your design system offering enough guidance to turn signals into clarity, or are you leaving teams to fill in the blanks on their own?
Build Your Not-So-Clandestine Design System Network
Design systems succeed and fail on trust. Contribution pipelines, while well-intentioned, often erode that trust by leaving contributors waiting and teams uncertain. Networks, on the other hand, earn trust by being active, intentional, and transparent.
That’s what SPYING is about: tuning into Signals, extending your reach through Partners, showing up as You, refining inputs into Intelligence, Navigating tensions, and delivering clear Guidance. Together, these practices transform design systems from passive responders into trusted guides.
Trust isn’t built by chance. It’s built by discipline, visibility, and the confidence that when a decision needs to be made, your system and team will be ready to act when it matters.