Complete the package or divide into phases.
The real question is: will the team actually be able to use what is delivered?
For most businesses, dividing into smaller phases is safer. A design system only holds value when the team truly applies it, which requires time to form habits. Completing everything at once may create an impressive library, but the actual usage rate is likely to be low. You should only finalize a phase when the scope is limited to a single product, the identity is confirmed, and the team has someone ready to take it on immediately.
- A small team with various products and a budget spread quarterly.
- want to see value early at each stage
- scope limited to a single product, with a hard launch date
- identity still evolving, should not be fully packaged yet
Most businesses ask this question because they want to optimize their budget. But the real question is: can your team adopt and truly use everything that is delivered? If unsure, phased delivery is a safer choice in most cases.
Why is application rate the correct measure
A design system is not a product that is complete once delivered. The real value lies in how the design and technical teams change their daily work practices. They use shared components instead of each person drawing them anew, and use tokens (design variables for colors, typography, spacing) instead of memorizing color codes. This requires time to form habits, not just a one-day file handover.
Nathan Curtis, who studies how organizations adopt design systems, sets clear principles. He believes progress should be measured by the actual adoption rate, not by the number of deliverables. A library of three hundred components that the team only uses twenty of means the rest is sunk cost.
The design system grows alongside the common language of the team, not as a one-time delivered document.
Alla Kholmatova, Design Systems (Smashing Magazine)
Factors you need to consider
- The size of the receiving team. The smaller the design and technical team, the more limited their capacity to digest at once. Staggering the process helps prevent them from feeling overwhelmed.
- Number of digital products and level of differentiation. A single product differs from three products, each with its own interface. The broader the scope, the riskier it is to execute all at once.
- The stability of the original identity. If the brand identity can still change, solidifying the design system now is the easiest way to avoid redoing it.
- Budget and financial rhythm. Committing everything at once requires immediate cash flow. Phased delivery allows you to allocate quarterly and adjust as needed.
- Disruption tolerance of parallel teams: If the technical team is continuously working on features, receiving a large design system at once will cause bottlenecks.
When to choose which direction
Divide into suitable phases when: the team is still small with fewer than ten people, the digital product has more than one context, the identity is not fully finalized, and the budget is spread quarterly. It is also suitable when you want to see real value at each stage before spending more. A common division is into three consecutive phases: reviewing and converting tokens, creating components and documentation, then implementing and managing.
Doing nearly everything at once is suitable when: the scope is limited to a single product, and the identity is fully finalized. It is also suitable when there is a hard launch date that requires everything to be completed in sync, and the team has someone ready to take it on from the first week. When these conditions are met, extending into multiple small phases can lead to inconsistency and additional coordination costs.
Common errors regardless of the chosen direction
- Order too many right at the start. Hundreds of components in the first month may sound effective, but most will sit idle because the team does not have real needs yet. Value does not lie in the quantity of deliverables.
- Consider the delivery date as the goal. The delivery date of the files is just the starting point of a more important phase: the team learning to use it and changing their habits. If this time is not accounted for in the plan, the adoption rate will be low regardless of how good the delivered product is.
- Dividing into phases but the first phase does not address real pain points. If the first phase solves a problem that the team does not feel pain from, they have no reason to change their approach. The first phase must target what the team is facing weekly, such as chaotic token colors or components being redone multiple times.
Decision checklist
Topic: How to package everything at once or break it into smaller phases. Sinh Vũ Handbook, sinhvu.com
Tick each item that applies or that you can already answer, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Nathan Curtis, EightShapes, Adopting Design Systems. Alla Kholmatova, Design Systems (Smashing Magazine). Practical experience from Sinh Vũ through the digital interface design process.
Frequently asked questions
If divided into batches, how long should each batch last?
There is no fixed number, but each phase should be long enough for the team to truly test and provide feedback, not just enough to deliver the files. You should look at the team's actual workflow to define the phases, rather than cutting according to a theoretical schedule.
Is completing the package more cost-effective?
Not necessarily. The cost of completing all components from the start may be lower if calculated simply. However, if most of the design system is not used, that cost is completely wasted. Phased delivery helps you pay for the actual scope needed first, and adjust in later phases after seeing how the team uses it.
What should be done in the first phase to show the team immediate value?
Choose a specific pain point that the team encounters weekly, such as color and typography tokens getting mixed up between files, and address that pain point first. If the first phase does not touch on the team's real issues, they will have no reason to change their working habits.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.