Start with the observable problem
Different buttons may reveal a missing shared component, but they may also mean that the team does not know which variant to use. Slowly built screens can be caused by inconsistent design, unclear requirements or fragile architecture. Name the problem before choosing the solution.
There are several levels between nothing and a complete system
- Foundation tokens for colour, spacing, typography and states.
- Reusable components for patterns that appear frequently.
- Short rules explaining when and how to use each variant.
- A versioned library with documentation and a contribution process.
- A design system managed as a product, with its own team and goals.
You can stop investing at the level that removes the actual friction. For a marketing site or an early product, the first three steps are often enough. Across multiple products and teams, the absence of versions and governance starts to become expensive.
When a design system becomes justified
The investment makes sense when several teams rebuild the same patterns, when differences cause errors and when the product is stable enough for rules to be standardised. It also matters who will answer questions, review contributions and manage breaking changes.
Standardisation also has a cost
Every published component becomes a promise. It must be tested, documented, updated and migrated. If a system tries to cover every imagined case in advance, its API becomes difficult to understand and teams work around it. A small, well-used core is more valuable than a large theoretical catalogue.
Decide based on frequency, risk and scale
- How often is the same solution repeated?
- How many teams and products need to use it?
- What risk does inconsistency create for users?
- How often do the product and identity change?
- Who has the time and authority to maintain the rules?
A good design system is not the largest possible system, but the smallest shared source of truth that reduces repeated work.