Rolling out a system is never "drop the library and pray". Each product needed something different.
Rolling out a system is never "drop the library and pray". Each product needed something different.
On smaller projects like Clutch a clean Figma library and a short guide was enough.
But for bigger ones like Telefónica, Sphera or Commons I needed an actual plan.
On smaller projects like Clutch a clean Figma library and a short guide was enough.
The team was small, the product was focused, and adoption happened naturally. A well-organized library and clear usage guidelines were all that was needed to get everyone on the same page.
But for bigger ones like Telefónica, Sphera or Commons I needed an actual plan.
Multiple teams, complex products, and existing patterns meant the rollout needed structure: clear documentation, training sessions, migration tracking, and support.
Clear docs on Zeroheight. Quick Loom videos. Usage rules. "When to use it", "when not to."
Documentation wasn't just a list of components. It included:
• clear usage guidelines
• "when to use it" and "when not to"
• quick video tutorials
• behavior rules and edge cases
When people know exactly how to start they adopt the system without you pushing it.
Then short training sessions so people knew how to migrate screens without breaking flows.
These sessions covered:
• how to use the library
• migration strategies
• common pitfalls to avoid
• how to maintain existing flows
Hands-on training meant teams could start using the system immediately without breaking what already worked.
For large migrations everything lived in Jira — what was updated, what was pending and what needed review. It kept the rollout controlled instead of chaotic.
Jira tracked:
• what screens were updated
• what was still pending
• what needed review
• blockers and dependencies
This visibility kept everyone aligned and the rollout moving forward without chaos. Teams knew what to work on, what was done, and what was next.
Rolling out a system is never "drop the library and pray".
Each product needed something different. Smaller teams needed simplicity. Bigger teams needed structure. Clear documentation, training, and tracking made the difference between adoption and abandonment.
When people know exactly how to start they adopt the system without you pushing it. The rollout becomes a natural part of their workflow instead of an extra burden.
Insights and learnings from building design systems across different products and teams.View all articles