🌏 閱讀中文版本
That “Convenient” Button in Figma
Sandy just joined the team as a UI designer.
She dragged a non-standard button in Figma.
It felt natural.
She didn’t use the Button component. Didn’t apply the primary style. Just drew a Frame and filled it with #1A2B3C.
Fast.
Three months later, that color value was scattered across 12 projects.
A senior engineer spent a full day patching style conflicts in the Design System.
This is the cost of scaling.
We think a Design System is a “component library.”
It’s actually a “boundary.”
Too narrow, and the product can’t grow.
Too wide, and maintenance costs eat the team alive.
91 components enough?
9 brand presets enough?
The answer: not quite — but not far off either.
The real question: what do you build next?
In the Mockup Stage, the Component Library Isn’t First
Let’s be clear.
Using standard components in the Mockup stage isn’t a bad approach.
It keeps visual communication consistent.
Designers don’t have to worry about whether the color value is right.
But here’s the thing: making components the star of the Mockup stage slows down exploration.
Most teams in the Mockup stage are doing work with diminishing returns.
Designers drag Button, Input, Modal in Figma.
It looks professional.
But at the lo-fi Mockup stage, these components add limited value.
Because the purpose of a Mockup is visual communication.
Communication needs flexibility.
You need to quickly try three different layouts.
You need to manually tweak a button’s shadow.
If you force designers to use “standard components”:
- They have to detach instances.
- They have to align manually.
- They have to worry about whether color variables are bound correctly.
In the end, designers will change colors manually anyway.
Because the primary blue in the standard component doesn’t fit the visual composition they’re going for.
So what a lo-fi Mockup stage actually needs is exactly one thing:
Design Tokens.
Not components. Tokens.
--color-primary-500
--spacing-md
--radius-lg
Designers just need to know the variable names.
They can compose freely in Figma.
As long as the token mapping is confirmed at export — through variables/style mapping or handoff spec.
Concretely, the layering in the Mockup stage should look like this:
| Layer | Defines | Lo-fi Mockup | Hi-fi Prototype / Implementation |
|---|---|---|---|
| Presets | Design Tokens | ✅ Needed | ✅ Needed |
| Constraints | Design rules | ✅ Needed | ✅ Needed |
| Components | Component specs | ⚠️ Depends on fidelity | ✅ Needed |
Lo-fi Mockups only need Presets + Constraints.
Components only come into play at the hi-fi prototype stage, or when handing off to engineering.
The full component tree runs at implementation.
Forcing a component library onto a lo-fi Mockup is like making a chef cook with seasoning packets during a tasting.
Of course the flavors will be consistent.
But you can’t tell what dish they’re actually trying to make.
How Many Brand Presets Does a Commercial Design System Need?
Our brand-presets currently has 9 options.
default, tech, finance, healthcare, ecommerce, luxury, playful, minimal, creative.
Seems like plenty.
But let’s look at what the market actually demands.
If you take on a government contract.
Is your corporate preset formal enough?
It isn’t.
Government sites need higher contrast and more conservative type ratios.
If you take on a healthcare app.
Is your healthcare preset warm enough?
It isn’t.
Healthcare needs trust — but not cold.
Current state: 9 presets.
Commercial recommendation: 12 industry presets as the base, plus 3-6 mood modifier layers on top.
Why this range?
Too few, and you can’t cover the mainstream industry contexts.
Too many, and maintenance costs outweigh the convenience of brand switching.
Each preset requires 8-12 core Tokens, plus example screenshots, demo pages, and ongoing updates.
Based on working with several internal teams, the practical ceiling for sustainable maintenance is around 15-18 commonly used combinations.
Beyond that, a Design System quietly becomes a file management system rather than a design tool.
Industry Presets — 12 Types
These 12 presets cover most common B2B and B2C contexts. Final coverage depends on your client portfolio.
| Preset | Industry Coverage | Key Differentiator |
|---|---|---|
corporate |
General enterprise, B2B | Standard business blue, steady |
finance |
Banking, insurance, investment | High contrast, rigorous, trustworthy |
healthcare |
Medical, pharma, health | Warm green/blue, readability first |
ecommerce |
E-commerce, retail | High-conversion palette, strong CTAs |
tech |
Tech startups, SaaS | Gradients, neon accents, modern feel |
luxury |
Premium brands, fashion | Low saturation, high contrast, whitespace |
playful |
Apps, games, children | Rounded corners, vivid colors, animation-ready |
minimal |
Japanese, Scandinavian, art | Ultra-minimal, monochrome, generous whitespace |
creative |
Design studios, artists | Asymmetric, experimental layouts |
warm |
Community, nonprofits, family | Warm palette, soft shadows |
bold |
Sports, music, youth | Heavy type, high contrast, impact |
government |
Government, public infrastructure | Formal, sans-serif, high legibility |
Mood Modifiers — The Overlay Layer
Mood isn’t a standalone preset — it’s a modifier layer stacked on top of an industry preset.
For example, corporate + bold for an internal company event page; healthcare + warm for a pediatric app.
3-6 modifiers is usually enough. More than that and they start to conflict with the industry presets.
But here’s the key:
You don’t need to build all 12 industry presets from day one.
Start with corporate and tech.
When the second industry need arrives, copy and adjust.
Incremental improvement beats heroic refactors.
Don’t try to predict five years of brand requirements upfront.
The market signal isn’t clear yet.
Handle today’s clearest needs first, then expand as the signals accumulate.
91 Components — Is That Actually Enough?
Leo is an engineer on our team.
He asked a question that comes up all the time: “We have 91 components — what are we missing?”
Coverage with 91 components:
| Category | Status | Examples |
|---|---|---|
| Basic UI | ✅ Complete | Button, Input, Select, Checkbox |
| Layout | ✅ Complete | Grid, Space, Divider, Layout |
| Navigation | ✅ Complete | Menu, Breadcrumb, Pagination, Tabs |
| Data Display | ✅ Complete | Table, List, Card, Tree |
| Data Input | ✅ Complete | Form, Upload, DatePicker, Transfer |
| Feedback | ✅ Complete | Modal, Message, Notification, Progress |
| Pro | ✅ Complete | ProTable, ProForm, ProLayout |
91 components = sufficient for most enterprise application scenarios.
What about the rest?
Specialized domain components.
| Category | Components | Recommended Approach |
|---|---|---|
| Data Visualization | Charts, Graphs | Integrate ECharts / G2 |
| Rich Text | Rich Text Editor | Integrate TipTap / Quill |
| Drag & Drop | Drag & Drop, Kanban | Integrate dnd-kit |
| Scheduling | Gantt, Calendar | Integrate FullCalendar |
| Map | Map | Integrate Mapbox / Leaflet |
| Code | Code Editor | Integrate Monaco / CodeMirror |
Build or wrap core components; integrate specialized ones.
This isn’t a technical choice — it’s a resource allocation trade-off.
The engineer’s thought: “Could we build our own Chart component that fits perfectly with the Design System’s style?”
The answer: yes — but the cost is high.
Chart.js, ECharts, G2 — these libraries carry years of community use, bug fixes, and browser compatibility work.
Mature chart libraries typically outperform a two-week in-house build on performance, accessibility, and browser compatibility.
The trade-off is clear:
- Core UI components (Button, Input, Modal): build or wrap headless/unstyled/mature libraries — but API and tokens are owned by the system.
- Specialized domain components (Chart, Map, Editor): integrate third-party first. Because this affects performance and professional quality.
Concretely, your Design System should provide “integration guides.”
Not “integrated components.”
An integration guide tells engineers:
- How to install ECharts.
- How to configure Theme Tokens.
- How to handle responsive layouts.
- How to ensure accessibility.
That way, you preserve brand consistency without taking on the maintenance burden of large third-party codebases.
Layered Design: Presets → Constraints → Components
How far a Design System scales depends on your layering strategy.
The bottom layer is Presets — a collection of Design Tokens.
Target: 12 industry presets plus 3-6 mood modifiers.
Purpose: fast brand switching.
Each preset needs 8-12 core Tokens.
The next layer up is Constraints — design rules.
They define the boundaries of component usage.
When do you use a Primary Button? When do you use a Text Button?
Purpose: give free exploration clear edges, and reduce the understanding gap between roles.
Maintained primarily through documentation, with code as a supplement.
The top layer is Components — runnable UI elements.
Around 91 core components.
Purpose: accelerate development, ensure consistency.
Maintained primarily through code, with documentation as a supplement.
These three layers are independent.
Presets can update independently.
Constraints can be revised independently.
Components can be upgraded independently.
Don’t mix them together.
Change one color and suddenly you’re testing 50 components.
I’ve seen teams stuck on this for two weeks.
The bottleneck in scaling isn’t component count — it’s boundary clarity.
Where Do You Draw the Boundary?
A Design System isn’t a project.
It’s infrastructure.
The quality of infrastructure doesn’t show up on day one.
It shows up in year one.
When your team grows from 5 to 50.
When your product expands from 1 to 10.
When your brand expands from 1 to 5.
You’ll be glad you got the layers right.
A Design System isn’t about going faster today.
It’s about keeping tomorrow’s expansion within maintainable boundaries.
But every team hits that maintenance threshold differently.
Is your Design System still adding components today — or drawing boundaries?
Sources
- Ant Design Component List — Enterprise-grade UI component library reference
- Brad Frost: Atomic Design — Theoretical foundation for Design System layering
- Design Tokens W3C Community Group — Design Tokens community technical report
- Spotify Design: Scaling our Design System — Scaling Design Systems in practice at large teams