Process Study • Governance • Design Systems
Component Library Governance
How Component Methodology removes subjectivity from component library decisions — and why that matters more than the components themselves.
The Problem
The Problem Has Two Faces
The first time I built a governance framework for a component library, the problem was too many opinions. At Advisor360°, we had a large design team, a large engineering team, and no shared standard for what belonged in the design system. Designers added components constantly. New patterns, new variations, new one-offs, each of which engineering had to build, document, and maintain. The library grew heavier with every sprint. Time to market slowed to a crawl, and the feedback designers received on their proposals varied depending on who was in the room and how they were feeling that day.
The same solution could get approved on Tuesday and rejected on Thursday. That's not a design problem. That's a decision-making problem.
The second time I applied this thinking, the problem looked completely different. At Noteefy, we had seven engineers (all database and backend specialists with limited front-end component experience), one designer functioning as product manager, and a component library I was building largely on my own. The engineers who consumed the library had no framework for deciding whether a change belonged in the library or in their local implementation. Without guidance, every ambiguous decision became a question directed at me. In an effort to not overload me, many engineers would make local components that would later need to be refactored in order to align them to the component library. I was the bottleneck.
Two different organizations. Two different failure modes. One framework that resolved both.
The Moment
The Moment That Made It Concrete
An engineer at Noteefy was working a bug. Tags in the Lead Management interface had no width constraint and long labels were breaking the layout. Their solution was to fix it in the application: add a width cap directly to the tag implementation in that view.
It would have worked. It also wouldn't scale.
The Fix Would Have Been Arbitrary:
We had no principled reason to choose one width over another.
It Would Have Been Local:
The same problem would resurface anywhere else tags appeared.
It Would Have Created Silent Inconsistency:
Two places in the system handling the same visual problem differently, for no reason anyone could later explain.
What the engineer needed wasn't a different answer. They needed a different question. Instead of "how do I fix this tag?" the right question was "where does this fix belong, and why?"
That's what the governance framework answers.
The Framework
Should This Change Be Made? The Three Questions
Every proposed change or addition to the component library passes through three questions, applied in order. The goal isn't to approve or reject — it's to find where the opportunity actually is. Nothing gets discarded; things that don't pass today get documented and revisited when the context changes.
01 / First gate
Start here
Can Existing Components Solve This?
We first determine if we have something that can solve this.
Yes
Use the existing solution.
No
Move to the Three Questions.
Move to the Three Questions
02 / First Question
Is It Crucial?
Is this the only way to solve this problem.
Yes
A change is necessary. Determine where it lives.
No
The proposal now has to pass both value tests: Beneficial and Reusable.
03 / Second Question
Is it Beneficial?
Does this objectively improve on what already exists?
Yes
Move to the next question.
No
This change should not be made.
04 / Third Question
Is it Reusable?
Would an engineer building a different app independently want this?
Yes
This change should be made. Determine where it lives.
Possibly
Revisit when a second independent need arrives
No
Pattern is too specific. Re-evaluate, redefine, and find the opportunity.
The Burden of Proof
The burden of proof belongs to the person proposing the change. Not to gatekeep, but for clarity. If you can't show why existing components fall short, or why your solution is objectively better and why the pattern serves more than your immediate context, the case isn't ready yet. The answer is never a flat no. It's "not yet — here's what needs to be true."
This is what solved the political problem at Advisor360°. When feedback is based on three objective questions rather than individual taste, the conversation changes. You're no longer arguing about whether something is good. You're establishing whether it meets the standard, and you're finding it together. That's a different conversation, and it's a much shorter one.
The Architecture
Where Does the Change Live?
Once a change clears the first determination, the second begins. The governing principle is capability vs. configuration.
The library owns capabilities — mechanisms, attributes, behaviors that make something possible. The instance owns configuration — the specific value or setting applied in a particular context.
The test: does this apply consistently across all contexts where this component is used?
Library: Fixed value.
The rule applies universally and there's no meaningful reason for it to vary. Set it once in the component. The lozenge max-width is the example: we needed a truncation limit, we chose a number, and there's no reason it should differ across contexts. Making it configurable would add complexity with no benefit.
Library: Configurable mechanism.
The need is consistent but the specific value legitimately varies. The library provides the capability; the instance provides the value. An input character limit works this way — the ability to constrain length belongs everywhere, but 64 characters for tags, 255 for a general field, 160 for SMS.
Local: For now.
You don't yet know whether the value is consistent across contexts. Keep it local, let usage accumulate, revisit when you can answer the question confidently. Flexibility kept local costs nothing. A rule amended later creates ripple effects through everything built against it.
Local is not a permanent state — it's a starting point. Document what you built, why it's local, and what evidence would graduate it upward. When you find yourself making the same local decision repeatedly and the value keeps holding, that's your signal.
The Example
The Tag Scenario, Resolved
Back to the engineer and the broken tag layout.
The UI is breaking — a change is necessary. But multiple solutions exist, so each gets evaluated separately.
Character limit on the input: Beneficial — prevents the problem at the source. Reusable — any length-sensitive input would independently want this. Proceed.
Max-width truncation on the lozenge: Beneficial — more flexible than a character limit, handles display gracefully regardless of data source. Reusable — lozenges appear across the system, not just in tags. Applying a single max-width at the component level solves the problem everywhere at once. Proceed.
Both pass. Both are right. They solve different problems — one is input governance, one is display governance. The engineer needed both, and now he had a principled reason for each.
The ability to limit input length is consistent across contexts → Library, configurable capability. The specific value of 64 characters for tags is context-dependent → Local instance, documented, with a note that if it holds across future tag-like inputs it becomes a library standard.
The lozenge max-width applies consistently across all lozenge contexts → Library, fixed value. No reason to make it configurable; doing so would add complexity with no benefit.
The engineer's original instinct — fix it in the application — would have solved today's problem and created three more. The framework pointed to the right place.
The Outcome
Two Builders. One Framework. 66% Faster.
66%
Reduction in time to market at Advisor360°
1 Week
Booking Engine built at Noteefy by one designer and five engineers. Functional demo in three days. The component system is why.
Small Team
Front-end engineering staff cut by more than half during a layoff. Time to market continued to decrease.
At Advisor360°, the library didn't get heavier under pressure. It held — because every component in it had a principled reason for being there. At Noteefy, the framework is newer, but the evidence is already in the Booking Engine. That velocity wasn't accidental. It came from a system where decisions had already been made, and engineers knew exactly where new elements belonged without asking.
The goal in both cases wasn't a better component library. It was a team that didn't need me to make every decision — because the framework made the same call I would have made, consistently, regardless of who was in the room.
The Insight
Remove Subjectivity, Remove the Bottleneck
The real cost of an ungoverned component library isn't the redundant components. It's the recurring meetings, the inconsistent feedback, the decisions that have to be made over and over because there's no standard to reference. Every one of those is a tax on the team's time and trust.
A governance framework doesn't slow the library down. It makes the library trustworthy — which is the only thing that makes it fast.