Blog Overview
The threshold is not company size. It is screens, roles, teams, and release cadence. A six-question readiness scorecard, what a system contains, and when a component sheet is enough.
The conversation about a design system usually starts after the product becomes messy: three primary buttons in different colours, four ways to show an error, and two pages that use spacing that does not match. Someone asks for “a design system,” and a new project begins that may run for months before it changes anything in the product.
The right question is not “do we need a design system?” but “what is the smallest system that prevents the next mess?” For many teams, the answer is a one-page component sheet and simple governance. For others, it is a full system with tokens, documentation, and tooling. This article helps you locate yourself.
The threshold is not company size
A ten-person company may need a system because it builds three platforms in two languages. A three-hundred-person company may not need one because it runs a single product with one design team. The real threshold is four numbers: screens, roles, teams that edit the interface, and releases per month.
Add a fifth factor: do you have more than one brand or more than one market? If yes, you need switchable tokens, not just tidy files. If the brand and market are single, a light system may be enough.
A six-question readiness scorecard
Score each question zero, one, or two, then add them up. The total is not a verdict, but it stops the conversation from going in circles.
| Question | 0 | 1 | 2 |
|---|---|---|---|
| Unique screens | Under 10 | 10 to 30 | More than 30 |
| User roles | One | Two | Three or more |
| Teams editing the interface | One | Two | Three or more |
| Languages or directions | One | Two without full RTL | Two with full RTL |
| Releases per month | Less than one | One to three | More than three |
| Brands or markets | One | Two | Three or more |
Zero to three: a component sheet is enough. Four to six: a light system with tokens and core components. Seven to nine: a full system that needs an owner and dedicated time. Ten to twelve: a multi-brand system that needs governance before build.
What a system actually contains
A system is not just a component library. It has five layers, and if one is missing it becomes a beautiful library nobody uses.
Tokens. Colour, type, spacing, radius, and elevation, with semantic names rather than visual ones such as “blue 500.”
Components. Every state: empty, loading, error, success, disabled, and permission denied.
Patterns. Forms, tables, navigation, search, filtering, and messaging. A component alone is not enough.
Documentation. When to use the component, when not to, and which rules cannot be broken.
Governance. Who approves a new component, how it is logged, how it is retired, and who owns the version.
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
When a component sheet is enough
If you have one product, one design team, fewer than thirty screens, and one brand, do not start a system project. Make a two-page sheet: buttons, fields, cards, tables, and messages, with their basic states. Add colour and spacing rules. That is enough for a year, and it saves you from building a system nobody needs.
The risk is not simplicity. The risk is calling the component sheet a “design system” and then adding tools and governance the team does not use. A system that is not maintained is worse than an honest sheet, because it creates a false sense of consistency.
The cost of inconsistency
Inconsistency does not appear on an invoice. It appears in review time, interface bugs, onboarding new staff, and customer complaints that say “the button does not work” when it is simply a different button. As the number of teams grows, the cost of verbal agreement grows with it.
The real gain from a system is not beauty. It is fewer repeated decisions: which colour for an error, which spacing between fields, which button is primary. Once those decisions are made once, the team's time moves to the problem, not the styling.
Add a less visible gain: accessibility. A component that carries a screen-reader name, correct focus order, and acceptable contrast passes those properties to every screen that uses it. A component that lacks them spreads the same defect everywhere, and fixing it later becomes a project rather than an edit.
A thirty-day start
Inventory existing components. Do not design from scratch before knowing what is actually in use.
Choose ten components only. Buttons, fields, cards, tables, alerts, modals, tabs, tags, navigation, and loading.
Define semantic tokens. Primary, danger, success, warning, text, background, and border.
Document the six states. Empty, loading, error, success, disabled, and permission denied.
Add Storybook stories. Every component in Arabic and English, in light and dark mode.
Name an owner. One person accepts or rejects new components.
Tie tokens to code. One token file becomes CSS variables, not two versions that drift.
Review after thirty days. What was used? What was not? Delete the unused.
Frequently asked questions
Do we need a design system if we are a small company? Usually not. You need a component sheet and simple rules, and you defer the system until you cross the threshold.
Do we start with tokens or components? With the components you use today, then extract the tokens from them. Starting with tokens and no usage produces a theoretical system.
How do we convince management? With review time and interface bugs, not a slide deck about beauty.
Does the system work with RTL? Only if it is designed for both directions from the start. Adding it later means rebuilding the components.
Who owns the system? One accountable person, even part-time. A system without an owner dies in three months.
Sources
- Material 3: bidirectionality and RTL — why components are designed for both directions.
- WCAG 2.2 — the acceptance criteria every component should carry.
- McKinsey: The Business Value of Design — why organised design compounds.
- Web platform development — how we tie tokens to components in the build.
- UI/UX design cost — where system work sits inside the scope.
