Should we test the sample product before scaling the design system?
Implementing a design system for the entire organization at once sounds quick, but often leads to discovering root errors when it is too late to fix them affordably.
Yes. Transitioning a sample product to the new system first is the safest way to reveal real vulnerabilities when the system interacts with live code, before the entire organization relies on it. A pilot (test product) also provides live evidence to persuade other teams and refine the onboarding process. Only skip the pilot if the system is very small and the organization has exactly one product.
- multiple products or teams, high risk of simultaneous duplication
- needs living proof to persuade internally
- only correct for a small product, compact team, and simple system
When the design system has been built to a basic level, the next question is always: how to implement it? Many organizations want to move quickly, applying it simultaneously to all products to quickly realize a return on investment. Sinh Vũ understands that mindset. However, practical experience, along with Nathan Curtis's framework from EightShapes, leads to the same conclusion: starting with a sample product is a safer and often faster overall path.
Why do we need sample point products?
The design system is built in a relatively clean environment: Figma, Storybook, internal documentation. However, when that system collides with a real product in operation, with legacy code, a separate release process, and a team with its own working habits, new gaps will emerge that cannot be anticipated.
A pilot (test product) serves one purpose: to expose those vulnerabilities before the entire organization relies on the system. Fixing root issues when only one team is affected is much cheaper than fixing them after ten teams have relied on the system for release.
Moreover, pilots create living proof. When you meet the second team and say "this system works well," that statement does not carry the same weight as pointing to a real running product and saying "this is the result."
Choose pilot products how.
Not every product is suitable to serve as a sample point. Three criteria need to be considered:
- Real enough to reveal the problem. A product that is too simple or too peripheral will not expose the real issues of the system. A pilot that runs well does not mean the system is ready for more complex products.
- Not too risky if issues arise. Do not choose products with the highest user traffic or those in a sensitive business phase as the first sample point.
- Is the team for that product ready and have a voice? A team that does not want to participate will provide superficial feedback. A team with a voice in the organization will ensure that lessons from the pilot are heard and addressed.
When to run a pilot, and when can be skipped
Should conduct a pilot when: the organization has multiple products or many independent teams, the risk of simultaneous scaling is high, the system has just been newly built and has no real precedent, or evidence is needed to convince internal stakeholders to accept the system.
Can you skip the pilot when: the organization has only one small product, the team is compact and familiar with working together, the system is simple, and the scope of changes is narrow. In this case, the entire organization is already a pilot.
Common errors in this phase
- Scaling the entire organization at once. When a root error occurs, the cost of fixing it multiplies according to the number of teams relying on the system.
- Select a pilot product that is too safe. The pilot runs well but does not reflect the true complexity of the other products. When scaling up, new issues arise and are misattributed to the system rather than to the pilot not being representative.
- No feedback loop after the pilot. Lessons from the pilot must have a mechanism to feed back into the system for corrections, not just reside in meeting minutes or personal notes from the pilot team.
Test a few groups on one or several products first to experience access, onboarding, and processes. Only expand later if successful.
Nathan Curtis, EightShapes, Adopting Design Systems
Sinh Vũ's viewpoint
In the implementation phase of A3 at Sinh Vũ, we start by transferring a sample product to the system first, along with an RFC (request for change) management process and a set of metrics to track adoption levels. This is not because the process requires it, but because we need to understand how the system operates in reality before allowing other teams to depend on it.
That product serves as both a test and proof. When the next team asks, 'Is this system working?', we don’t need to persuade with words. Just point to the running product.
You don’t need a perfect pilot. You need a pilot that is real enough to teach something that no lab environment can.
Decision checklist
Topic: Should you test on a sample product first before scaling up. Sinh Vũ guide, 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. Practical experience in implementing A3 at Sinh Vũ Studio.
Frequently asked questions
How long should a pilot last to be sufficient for scaling?
There is no fixed number. A pilot is sufficient when the component set (interface elements) has been used in at least one real release cycle, core errors have been recorded and fixed in the system, and the onboarding process has been validated at least once. A pilot team that can operate independently without continuous support from the system team is a good sign for expansion.
If the pilot product is successful but another team doesn't want to adopt it, what should we do?
This is a management issue, not a technical one. Live evidence from a pilot is a more persuasive tool than slides or policy documents. If another team still refuses, it’s important to understand the specific reasons: lack of resources, concerns about control, or the system not meeting their actual needs. Each reason requires a different approach and should not be forced until the root cause is addressed.