How to handle design system requests you can't prioritize

Somewhere in your backlog there's a component request that's been sitting for four months. The team that filed it has stopped asking about it. They've either built the component themselves, found something close enough to use incorrectly, or just shipped something inconsistent and moved on. The request is technically still open. The problem it was meant to solve has been solved in a way that now needs to be undone.

Silence on a design system request is not a neutral state. It produces outcomes, usually bad ones, independently of whether the system team intended to produce them.

What teams do when they don't hear back

The behavior of a product team that filed a design system request and received no response is predictable. In the first two weeks, they assume the request is being considered. After a month, they start working around it. After two months, they've either built the component themselves or adapted an existing component in a way the system didn't intend.

Both of those outcomes create future work. The custom component built by a product team may be technically sound but won't match the system's accessibility patterns, naming conventions, or visual language. If the system team eventually ships the canonical version, there's now a migration to consider. The adapted component creates a fork in usage that makes design review harder.

The perverse outcome: the team that received no response built something, and the system team now has to clean up what they built. Less responsive to requests does not mean less work.

The first response problem

Design system teams often treat "we haven't decided yet" as a reason to wait before responding. It isn't. The response that takes two days to send should not wait for the decision that takes three months to make.

An initial response within a week, acknowledging the request, asking clarifying questions if needed, and giving a rough timeline for when a decision will be made, prevents the silence that triggers product teams to go build their own solution. It doesn't require the team to commit to anything. It requires communicating that the request was received and is being considered.

This sounds obvious. It is obvious. Most design system teams don't do it systematically because triaging requests feels like a lesser priority than building things. The triage is the work. A team that responds promptly to requests, even with "not this quarter," maintains better relationships with product teams than a team that ships great components but treats requests as interruptions.

The clear "no" is a gift

Telling a product team that a request won't be prioritized, ever or not in the next six months, is a gift. It sounds harsh. It is kind. The team can now build the right solution for themselves, document it, and make an independent decision about whether to bring it back as a contribution later.

What makes a "no" a gift rather than a door closing is what accompanies it. A rationale. Some criteria for what would change the answer. An invitation to contribute or a clear statement of why this doesn't meet the threshold for the system.

"This is too specific to your surface to generalize well, and here's what would need to change for it to be a system component" gives the team information they can act on. "Not prioritized" with nothing attached gives them an ambiguous outcome that they'll interpret as "maybe later" and re-file in three months.

Managing the public backlog

A visible, maintained backlog of design system requests changes the dynamic of prioritization conversations. When teams can see what's been requested, what's been decided, and what's in progress, they have context for their own request. They can see if someone else has filed something similar. They can add votes or context to an existing request rather than duplicating it.

The backlog that exists only in a Jira project the system team maintains internally produces a different dynamic: teams file requests without knowing what else has been filed, the system team reviews them without the community context of who else has similar needs, and the prioritization process is invisible. The most vocal team gets the most attention, which is not the same as the most important need getting addressed.

Making the backlog public, even a simple Notion table with slug descriptions and statuses, doesn't add much maintenance overhead and substantially improves the quality of prioritization conversations. Teams see the full picture. The system team makes decisions that are visible and therefore more legible.

Triage as a team habit

The pattern that works: a weekly or bi-weekly triage pass over incoming requests. Someone on the system team is responsible for this rotation. Every new request gets an initial response within the week. Every existing request that hasn't moved in more than a month gets a status update sent to whoever filed it.

This isn't a large time investment. 30 to 45 minutes per week for a mature system receiving five to ten requests in that period. But without someone owning it explicitly, it doesn't happen. Triage falls to whoever happens to notice a new request, which means some get prompt attention and others sit unread for months.

The teams that trust the design system are the ones that have had their requests acknowledged, reasoned with, and either acted on or clearly declined. Trust doesn't require saying yes. It requires treating the request as real.