Accompanying the technical team: how many sessions are sufficient
One-off onboarding followed by abandonment is the most common reason design systems fail shortly after launch.
There is no golden number applicable to all teams, but the sufficient principle is: the team should be able to build a real screen using the system without needing further assistance. Sinh Vũ typically conducts 3 to 5 pairing sessions during the building phase, along with light support channels in the first three months. The specific number depends on the team's size, the complexity of the system, and the technology stack being used.
- a team using the system for the first time, with a complex stack, needing many sessions and sample projects
- maintain on-call hours when the new system launches and multiple teams are online
- the team is accustomed to systematic approaches (including a compact self-service Storybook)
- Cut duplicates to save, resulting in low usage rates.
Accompanying the technical team is not an afterthought once the system is completed. This is a crucial part of whether the system is truly usable or just exists on paper. Brad Frost, author of Atomic Design, clearly states: documentation, management, and support must be considered core components of the system product, not just supplementary infrastructure. Sinh Vũ agrees with this perspective and applies it to every deliverable project.
Deciding factors for the number of sessions
There is no fixed formula because each team brings a different set of conditions. Before agreeing on the number of sessions, Sinh Vũ usually needs to know four things clearly:
- Is the team familiar with the system approach yet. A team encountering a design system for the first time will need more pairing sessions than a team that has previously operated a similar system.
- Technology stack complexity. The more specialized the stack, the longer it takes to integrate components into the actual product, requiring more sessions.
- Is there a Storybook or self-service interactive documentation? If so, the team can look it up between sessions, helping to reduce the total number of direct mentoring hours.
- Who will take over the role of brand steward in the long term. This person needs to be closely mentored by the rest of the team, as they will be the one answering questions for colleagues after the contract ends.
Framework for mentoring used by Sinh Vũ
Sinh Vũ does not separate theory sessions from practical sessions. The learning method is to transfer a sample product to the team, allowing them to learn by doing from the very first session.
- Pairing phase while building the system: About three to five sessions, depending on scale. Each session focuses on a specific task, from setting up tokens (design values like color, font size, spacing) to integrating components into a real screen.
- Sample point projects: Work with the team to transition an existing product or screen to the system, not a simulated screen. This is the most accurate test to identify where the team is facing challenges.
- Support channel for the first three months: Not just additional support, but a live chat or hotline for the team to ask questions when encountering new situations. Three months is the time frame when the team starts to face various scenarios beyond what was covered in the pairing session.
Include a compact self-service Storybook suitable when the team is familiar with systemizing and simple stacks. Saves time, but is only effective if the interactive documentation is good enough for the team to reference themselves.
Common errors when onboarding the technical team
Sinh Vũ encounters these three recurring mistakes in many organizations, regardless of size:
- One-time onboarding then release. The team understands the concepts but cannot implement them independently. After a few weeks of not using it, they forget and revert to manual methods. The system is still there, but no one uses it.
- Only provide documents, no collaborative sessions. Documents answer known questions. Direct pairing sessions reveal questions the team did not know they had.
- Cut mentoring to save budget. Nathan Curtis of EightShapes clearly notes: the adoption rate increases when the team is helped to understand how to use each step, rather than receiving the entire system at once and feeling overwhelmed. Cutting mentoring to save often leads to low usage rates and requires much more costly revisions.
Documents, management, and support should be considered the core part of the system product, not just supplementary infrastructure.
Brad Frost, Atomic Design, Maintaining Design Systems
The viewpoint of Sinh Vũ
Sinh Vũ does not provide a fixed session number before knowing your team. However, there is a clear threshold to know when onboarding has been sufficient: the team can independently create a real screen using the system without needing further questions. Once that threshold is reached, transitioning to light support channels is reasonable. Before reaching that threshold, ending early poses risks for both parties.
The number of three to five sessions that Sinh Vũ often mentions is a starting point for discussion, not a commitment. For larger teams or complex systems, the actual number may be higher. More important than the number of sessions is the structure: each session must end with a tangible task that the team can complete, not just a slide deck.
Decision checklist
Topic: How many onboarding mentoring sessions are needed for the technical team using the design system. 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
Brad Frost, Atomic Design, chapter Maintaining Design Systems. Nathan Curtis, EightShapes: Adopting Design Systems.
Frequently asked questions
We already have Storybook, does the team need to include more sessions?
The storybook helps the team self-research, but it cannot replace real collaborative sessions. If the team is accustomed to systematic work, the number of pairing sessions can be reduced, but at least one to two sessions are still needed to see how the team integrates components into the actual product flow, identifying issues early.
After three to five pairing sessions, can the team really run on their own?
You can handle tasks you've done before, but there will still be questions when encountering new situations. That's why it's necessary to maintain a light support channel, either through direct hours or chat, for the first three months after handover. When the system is still new and many teams are using it simultaneously, this ongoing support time needs to be longer.
If the budget is limited, can we cut the coaching session?
Cutting paired sessions to save costs often leads to higher expenses later: the team has to redo work manually, the system is not utilized, and everything must be redone from scratch. If the budget is truly tight, prioritize maintaining pairing sessions on sample projects and reduce theoretical sessions, as learning through real work is much more effective than reading materials.