I have worked with systems that had more than 100 components.
The funny thing is that, at a certain point, no one on the team really knew which was the right one for each context.
Endless discussions, misplaced tickets, legal blocks due to lack of traceability, and developers losing concentration every two minutes...
The result was clear: the system was not invisible.
It was noisy. And expensive.
Well-designed infrastructure disappears.
Like a city's plumbing: you only notice it when it fails.
Pretty ✨
Documented 📚
Useless 🗑️
Because they don't solve the real problem:
* Teams losing days debating which button to use
* Developers losing context every two tickets
* Legal blocking changes due to lack of traceability
* No one measuring invisible debt
That time lost regaining focus after each interruption.
You don't see it on dashboards.
But it's what destroys sprints.
#
#
#
10-15 core components.
Not 146.
The rest are variants or compositions.
Why does it matter?
* If you have 146 components, you surely have 12 buttons, 8 inputs, 6 date pickers...
* Each team will use a different one, no one will know which to update, and technical debt grows in secret.
* When you want to change a global behavior, you end up touching 10 files and crossing your fingers so nothing breaks in production.
#
#
#
The typical problem in banking:
You have a payment form.
Spain needs to show a specific legal disclaimer.
Germany needs a different field order due to regulation.
France needs translation + a different number format.
Result: 15 variants of the same form.
All slightly different.
All require separate maintenance.
Fork hell.
#
#
#
Stripe has a single payment component that works in 40+ countries.
How?
Differences live in configuration, not in code:
The component is the same.
The logic is the same.
Only the configuration changes.
You update the JSON -> it propagates to all markets.
Zero forks.
🔗 [Stripe Localization](https://stripe.com/docs/payments/payment-methods#localization)
Other examples of what Stripe does well:
✓ Real-time IBAN validation: You don't wait days to know a format is incorrect. You know it while typing.
✓ Regulated error handling: Clear messages with specific codes. Legal approves templates once, not every screen.
✓ Strong Authentication (SCA): The system automatically detects when it is necessary by regulation and shows it only then.
The lesson:
They turn regulatory complexity into a competitive advantage.
It's not magic. It's infrastructure design.
📝 [As I explained in this post: when your prototype starts lying to you, it's because you didn't design infrastructure, you designed theatre](https://buildsystems.substack.com/p/the-day-our-perfect-prototype-started-lying-to-us-61971324637e)
Systems that are invisible but essential.
That prioritize operability over aesthetics.
#
#
#
Accessibility, traceability, consistency.
The system verifies it. Not goodwill.
Why does it matter?
Because if validation depends on someone remembering to review, sooner or later it fails.
Accessibility:
Automatic contrast tests, header hierarchy, keyboard navigation.
If a component doesn't meet WCAG AA, it doesn't go to production. Automatically.
And this is not optional:
The European Accessibility Act comes into force in June 2025.
Banking apps are required to comply with WCAG 2.1 level AA.
It's not a recommendation. It's law. With fines.
If your accessibility validation is manual, you're already late.
#
#
#
Not in Figma.
Not in third-party tools that control your costs.
Let's talk real numbers:
Typical banking team: 100 developers + 20 UX
Figma cost in 2019:
* Professional: €12/editor/month
* 20 UX editors = €240/month = €2,880/year
* Free viewers for developers
Figma cost in 2024:
* Professional: €15/editor/month (25% increase)
* Organization: many companies need this plan now
* Organization: €45/editor/month
* 20 editors = €900/month = €10,800/year
But here's the problem:
Now Figma charges for "viewer seats" in Enterprise plans for full access to shared libraries.
Enterprise plan (the one you really need for governance):
* Estimated price: €75-100/seat/month
* 120 users (20 UX + 100 devs needing access) = €9,000-12,000/month
* = €108,000-144,000/year
4,000% increase.
And you don't control:
* When prices go up
* What new features you're forced to pay more for
* If tomorrow they decide to change the licensing model
The real risk is not just the money, but that your governance depends on external decisions. That's why the source of truth must be internal and controlled by your organization.
Why does it matter so much?
Because you need something that:
* For Product Managers:
When a CFO asks "why does this copy work better?", you can't respond "it's in a Figma file someone moved from a folder".
You need real data, clear versioning, traceable history.
Show what was approved, when, by whom, and what results it gave.
* For Development:
If the source of truth changes every week because someone updated Figma without warning, developers stop trusting.
Internal documentation, versioned and synchronized with the code, eliminates ambiguity.
No debates. No blocks.
* For Legal:
When regulators ask "what exactly did you show 6 months ago?", you can't depend on Figma's history.
You need an immutable system.
That survives changes in tools, prices, or external policies.
That responds to audits without collapsing the team.
It's not "DS adoption".
Every minute lost regaining context is silent debt.
The kind that kills projects without anyone seeing it coming.
What worked, what failed, what changed. It's not show & tell, it's honest retrospective.
-> Documented decisions that are actually used
An ADR (Architecture Decision Record) is not a PDF no one opens again.
It's answering "why did we do it this way?" without needing meetings.
When someone new asks, there's a clear document that explains:
* What we decided
* Why we decided it
* What alternatives we considered
And it's linked to the code, not buried in Confluence.
-> Prioritized technical debt maps based on real cost
Not on political urgency. On how much it hurts to maintain it.
Leading a DS is not "delivering faster".
It is:
* Aligning incentives between teams
* Negotiating exceptions with an expiration date
* Reducing debt silently, without noise
The best system leader is the one least noticed.
Because the system works alone.
💬 Questions for systems leaders:
What metric do you use to detect fragmentation?
Where does your source of truth live?
How much do you lose every time your team deviates from the flow due to ambiguities?
👇 Share in comments 👇
#DesignSystems #EnterpriseDesign #ProductLeadership #Banking #Governance
The funny thing is that, at a certain point, no one on the team really knew which was the right one for each context.
Endless discussions, misplaced tickets, legal blocks due to lack of traceability, and developers losing concentration every two minutes...
The result was clear: the system was not invisible.
It was noisy. And expensive.
Well-designed infrastructure disappears.
Like a city's plumbing: you only notice it when it fails.
❌ The problem no one admits:
Most Design Systems in banking are UI catalogs with a brand manual.Pretty ✨
Documented 📚
Useless 🗑️
Because they don't solve the real problem:
* Teams losing days debating which button to use
* Developers losing context every two tickets
* Legal blocking changes due to lack of traceability
* No one measuring invisible debt
That time lost regaining focus after each interruption.
You don't see it on dashboards.
But it's what destroys sprints.
✅ How to build an invisible system:
#
#
#
1️⃣ Small and non-negotiable core
10-15 core components.
Not 146.
The rest are variants or compositions.
Why does it matter?
* If you have 146 components, you surely have 12 buttons, 8 inputs, 6 date pickers...
* Each team will use a different one, no one will know which to update, and technical debt grows in secret.
* When you want to change a global behavior, you end up touching 10 files and crossing your fingers so nothing breaks in production.
#
#
#
2️⃣ Controlled regional variations
The typical problem in banking:
You have a payment form.
Spain needs to show a specific legal disclaimer.
Germany needs a different field order due to regulation.
France needs translation + a different number format.
The trap:
Each team creates its own version of the component.
Result: 15 variants of the same form.
All slightly different.
All require separate maintenance.
Fork hell.
#
#
#
How Stripe solves it (and how you should solve it):
Stripe has a single payment component that works in 40+ countries.
How?
Differences live in configuration, not in code:
{
"ES": {
"legalDisclaimer": "Texto específico español",
"fieldOrder": ["email", "card", "name"],
"dateFormat": "DD/MM/YYYY"
},
"DE": {
"legalDisclaimer": "Gesetzlicher Hinweis",
"fieldOrder": ["name", "card", "email"],
"dateFormat": "DD.MM.YYYY"
}
}
The component is the same.
The logic is the same.
Only the configuration changes.
You update the JSON -> it propagates to all markets.
Zero forks.
🔗 [Stripe Localization](https://stripe.com/docs/payments/payment-methods#localization)
Other examples of what Stripe does well:
✓ Real-time IBAN validation: You don't wait days to know a format is incorrect. You know it while typing.
✓ Regulated error handling: Clear messages with specific codes. Legal approves templates once, not every screen.
✓ Strong Authentication (SCA): The system automatically detects when it is necessary by regulation and shows it only then.
The lesson:
They turn regulatory complexity into a competitive advantage.
It's not magic. It's infrastructure design.
📝 [As I explained in this post: when your prototype starts lying to you, it's because you didn't design infrastructure, you designed theatre](https://buildsystems.substack.com/p/the-day-our-perfect-prototype-started-lying-to-us-61971324637e)
Systems that are invisible but essential.
That prioritize operability over aesthetics.
#
#
#
3️⃣ Integrated automatic validation
Accessibility, traceability, consistency.
The system verifies it. Not goodwill.
Why does it matter?
Because if validation depends on someone remembering to review, sooner or later it fails.
Accessibility:
Automatic contrast tests, header hierarchy, keyboard navigation.
If a component doesn't meet WCAG AA, it doesn't go to production. Automatically.
And this is not optional:
The European Accessibility Act comes into force in June 2025.
Banking apps are required to comply with WCAG 2.1 level AA.
It's not a recommendation. It's law. With fines.
If your accessibility validation is manual, you're already late.
#
#
#
4️⃣ Internal Source of Truth
Not in Figma.
Not in third-party tools that control your costs.
Let's talk real numbers:
Typical banking team: 100 developers + 20 UX
Figma cost in 2019:
* Professional: €12/editor/month
* 20 UX editors = €240/month = €2,880/year
* Free viewers for developers
Figma cost in 2024:
* Professional: €15/editor/month (25% increase)
* Organization: many companies need this plan now
* Organization: €45/editor/month
* 20 editors = €900/month = €10,800/year
But here's the problem:
Now Figma charges for "viewer seats" in Enterprise plans for full access to shared libraries.
Enterprise plan (the one you really need for governance):
* Estimated price: €75-100/seat/month
* 120 users (20 UX + 100 devs needing access) = €9,000-12,000/month
* = €108,000-144,000/year
4,000% increase.
And you don't control:
* When prices go up
* What new features you're forced to pay more for
* If tomorrow they decide to change the licensing model
The real risk is not just the money, but that your governance depends on external decisions. That's why the source of truth must be internal and controlled by your organization.
Why does it matter so much?
Because you need something that:
* For Product Managers:
When a CFO asks "why does this copy work better?", you can't respond "it's in a Figma file someone moved from a folder".
You need real data, clear versioning, traceable history.
Show what was approved, when, by whom, and what results it gave.
* For Development:
If the source of truth changes every week because someone updated Figma without warning, developers stop trusting.
Internal documentation, versioned and synchronized with the code, eliminates ambiguity.
No debates. No blocks.
* For Legal:
When regulators ask "what exactly did you show 6 months ago?", you can't depend on Figma's history.
You need an immutable system.
That survives changes in tools, prices, or external policies.
That responds to audits without collapsing the team.
📊 The metric that matters:
It's not closed stories.It's not "DS adoption".
Every minute lost regaining context is silent debt.
The kind that kills projects without anyone seeing it coming.
🔄 The rituals that keep the system alive:
-> Learning demos, not just feature demosWhat worked, what failed, what changed. It's not show & tell, it's honest retrospective.
-> Documented decisions that are actually used
An ADR (Architecture Decision Record) is not a PDF no one opens again.
It's answering "why did we do it this way?" without needing meetings.
When someone new asks, there's a clear document that explains:
* What we decided
* Why we decided it
* What alternatives we considered
And it's linked to the code, not buried in Confluence.
-> Prioritized technical debt maps based on real cost
Not on political urgency. On how much it hurts to maintain it.
Leading a DS is not "delivering faster".
It is:
* Aligning incentives between teams
* Negotiating exceptions with an expiration date
* Reducing debt silently, without noise
The best system leader is the one least noticed.
Because the system works alone.
🎯 If the system is seen, it interrupts.
If it helps, it disappears.💬 Questions for systems leaders:
What metric do you use to detect fragmentation?
Where does your source of truth live?
How much do you lose every time your team deviates from the flow due to ambiguities?
👇 Share in comments 👇
#DesignSystems #EnterpriseDesign #ProductLeadership #Banking #Governance