Design system articles online are mostly written by FAANG teams with full-time platform designers. If you're a team of 1–8 designers, that advice will sink you. Here's the pragmatic design system we run at HK Infoway, and how it scales.
Three Figma files, not thirty
Most over-engineered systems split into 20+ libraries. We use three:
- Tokens, colour, spacing, radius, typography, shadow. Pure Figma variables.
- Primitives, buttons, inputs, cards, badges, navigation. Atoms and molecules.
- Patterns, page templates, complete flows, marketing modules. Organism level.
Variables before components
The biggest mistake we see: teams build components first, then retrofit variables. Reverse it. Spend a week getting tokens right, semantic naming (--color-surface-strong not --color-grey-900), mode-switching for dark/light, contextual collections. Components built on solid tokens age better.
Naming convention that survives 3 years
We use Category / Component / Variant / State. Example: Button / Primary / Default / Hover. Predictable, searchable, and rename-friendly when the inevitable rebrand happens.
Component variant discipline
If a button has 9 variants × 4 sizes × 3 states, that's 108 combinations. Don't build all of them. Build the 12 actually used. Add more when they're actually needed.
Handoff that engineers don't hate
Three things engineers thank us for: every interactive element has hover/focus/disabled states defined; every component has a usage note; every variable maps to a CSS custom property we both agree on.
AI in the design system loop
We use Figma AI for component naming consistency checks and to spot orphan layers. V0 and Galileo for first-pass page exploration, then we hand-tune in Figma. The system gives the AI structure to riff against.
See our full UI/UX services, browse the design portfolio, or join our design team.
