Complete the package or divide into phases.
The question is not about how much is done, but whether the team can actually use what is delivered.
For most businesses, breaking down into smaller batches is safer, as the design system is only valuable when the team truly applies it, which requires time to form habits. Completing everything at once can create an impressive library but with a low usage rate. You should only finalize a batch when the scope is limited to one product, the identity is confirmed, and the team has someone ready to take it on.
- 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 not whether to spend a lot or a little money at once, but whether your team can absorb and truly utilize everything that is delivered. If unsure, splitting the delivery is a safer option in almost every case.
Why is application rate the correct measure
The digital design system is not a product that is complete upon delivery. Its true value lies in how the design and engineering teams change their daily workflows, using shared components instead of each person redrawing, and using tokens (shared design variables for color, typography, spacing) instead of memorizing color codes. This requires time to form habits, not just a day to deliver files.
Nathan Curtis, a researcher on how organizations adopt design systems, sets a clear principle: measure progress by the actual adoption rate, not by the number of deliverables. A library of three hundred components that the team 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
- Team intake scale. A smaller design and technical team has limited capacity to digest at once. Staging helps them avoid 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.
- Stability of the core identity: If the brand identity can still change, creating a complete design system immediately is the fastest way to avoid redoing it.
- Budget and financial rhythm: Committing the entire amount at once requires immediate cash flow. Splitting it allows you to allocate by quarter 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
Dividing into appropriate phases when: the team is small with fewer than ten people, the digital product has more than one different context, the identity is not fully finalized, the budget is spread quarterly, or you want to see real value at each stage before spending more. Sinh Vũ builds A3 in three consecutive phases: reviewing and converting tokens, creating components and documentation, then implementing and managing. Clients pay according to the actual scope needed first, seeing value at each stage.
Creating a near-complete package is suitable when: The scope is limited to a single product, the identity is fully locked in, there is a hard launch deadline that must be completed synchronously, and the team has someone specialized to take over right from the first week. When all these conditions are met, extending into many small batches can lose consistency and incur 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.
- Viewing the delivery date as the finish line. The delivery date of the file is just the starting point of a more important phase: the team learns to use it and changes habits. If this time is not accounted for in the plan, the adoption rate will be low regardless of how good the deliverable 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.
The viewpoint of Sinh Vũ
Sinh Vũ does not recommend a big bang approach for the design system unless the conditions mentioned above are met. The practical reason: each small rollout forces both sides to sit down and see if the team is truly using what has just been delivered. That feedback will shape the next phase better than any long-term plan written from the first week.
Phased adoption is not a sign of a project lacking vision. It is a way for the design system to truly live within the organization, rather than sitting in a Figma library that no one opens.
Decision checklist
Topic: How to package everything at once or break it into smaller phases. Sinh Vũ Handbook, sinhvu.com
Select each item you find appropriate, 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 of Sinh Vũ through the A3 process.
Frequently asked questions
If divided into batches, how long should each batch last?
There is no fixed number, but each session should be long enough for the team to truly test and provide feedback, not just enough to hand over files. Sinh Vũ often looks at the actual workflow rhythm of the team to determine the session length, rather than cutting it according to a theoretical schedule.
Is completing the package more cost-effective?
Not certain. The cost of completing all components from the start may seem lower if calculated simply, but if most of the design system is not used, that cost is completely lost. Staging helps you pay for the actual needed scope first, adjusting in the next phase after seeing how the team uses it.
What should be done in the first phase to show the team immediate value?
Identify a specific pain point the team faces weekly, such as color tokens and text getting mixed up across files, and address that pain point first. If the initial round does not tackle the team's real issue, they will have no reason to change their working habits.