I spent two years building and maintaining a design system for Bluelearn — India's largest student community with over 100k members. Here's what I learned about making systems that actually work.
Start with atoms, not pages
We used Atomic Design methodology — atoms, molecules, organisms. The temptation is to start with pages and work backwards. Don't. Start with the smallest pieces and compose upward.
Our atoms included:
- Color tokens
- Typography scale
- Spacing units
- Border radii
- Shadow definitions
Everything else was built from these. When we needed to change the primary color, we changed one token and 200+ screens updated automatically.
The documentation problem
A design system without documentation is just a Figma file. We learned this the hard way. Developers would look at a component and guess how it worked. They'd guess wrong.
The fix was adding descriptions directly to Figma components. Every component got:
- A usage note (when to use it)
- Property descriptions (what each variant does)
- Do/don't examples
File organization matters more than you think
We started with one massive Figma file. It crashed constantly. RAM issues. Loading times. Merge conflicts.
We restructured into a three-tier hierarchy:
- Level 1: Department divisions
- Level 2: Feature-based files
- Level 3: Pages within files
The performance improvement was immediate. But more importantly, it made ownership clear. Each team owned their feature files.
The real lesson
A design system is a product. It needs users, feedback loops, versioning, and maintenance. If you treat it as a side project, it will die as a side project.