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 every team, but the sufficient principle is: the team should be able to build a real screen using the system without further questions. The number of pairing sessions depends on the team's size, the complexity of the system, and the technology stack being used, and there should be an additional light support channel after the setup, as new questions only arise when the team encounters real situations.
- 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.
Pairing with the technical team is not an additional decoration after the system is completed. This is a crucial part that determines whether the system is truly used or just exists on paper. Brad Frost, the author of Atomic Design, clearly states: documentation, management, and support must be considered the core of the system product, not a secondary infrastructure.
Deciding factors for the number of sessions
There is no fixed formula as each team brings a different set of conditions. Before agreeing on the number of sessions, it is essential to clearly understand four factors:
- 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 should include
Effective pairing does not separate theoretical sessions from practical ones. The learning method is to transition a sample product into the system alongside the team, allowing them to learn through real work right from the first session.
- Pairing phase while building the system: The number of sessions depends on the team's size. 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.
- Ongoing support channel after setup: This is not an additional pairing, but office hours or a chat channel for the team to ask questions when encountering new situations. This is when the team begins to face various scenarios beyond what was covered in the pairing sessions.
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
These three mistakes are repeated 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
How to know if onboarding is sufficient
There is a clear threshold to know when onboarding is sufficient: the team should be able to build a real screen using the system without further questions. Once this threshold is reached, transitioning to a light support channel is reasonable. Before reaching this threshold, ending pairing early poses risks for both parties.
What matters more than the number of sessions is the structure: each session must end with a tangible task that the team can complete independently, not just a slide presentation. For larger teams or complex systems, the actual number of sessions will be greater than for smaller teams using simpler systems.
Decision checklist
Topic: How many onboarding mentoring sessions are needed for the technical team using the design system. Sinh Vũ guide, 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
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?
Storybook helps the team self-research, but it cannot replace the hands-on sessions in real work. If the team is already familiar with the system, the number of pairing sessions can be shortened, but at least a few sessions are still needed to see how the team integrates components into the actual product flow, identifying bottlenecks early.
After the pairing sessions, can the team really operate independently?
You can manage the tasks you've completed, but there will still be questions when encountering new situations. That is why it is necessary to maintain a light support channel, whether through office hours or a chat channel, for a period after handover. When the system is still new and many teams are adopting it simultaneously, this ongoing support time needs to be extended.
If the budget is limited, can we cut the coaching session?
Cutting pairing sessions to save costs is often a choice that leads to greater expenses later: the team returns to manual work, the system is not used, and then has to be redone from scratch. If the budget is really tight, prioritize keeping pairing sessions on the sample project and cut theoretical sessions, as learning through real work is much more effective than reading documentation.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.