iStaging builds multiple products — VR Maker, CURATOR, ONE App, the Vision Pro viewer, client projects like the SEIC configurator — but each had evolved its own visual language, spacing conventions, and component patterns. Colors were hardcoded per file, spacing was inconsistent across screens, and every new product meant rebuilding basic components from scratch. There was no single source of truth, which meant design inconsistency, duplicated effort, and friction in developer handoff.
I initiated this project because I saw the cost of not having a system compound with every new product launch. The challenge was building something flexible enough to serve products with very different contexts — a web-based CMS, a mobile scanning app, a spatial computing interface, and client-facing configurators — while maintaining enough consistency that they feel like they belong to the same family. The system also needed to be practical for a solo designer: I could not build an enterprise-scale system that requires a team to maintain.
I started by auditing every existing product for color values, spacing patterns, typography scales, and component variants. The audit revealed over 40 unique color values where there should have been 12, and three different spacing scales in active use. I designed a three-tier token system: primitive tokens (raw values), semantic tokens (purpose-based naming like text-primary, surface-elevated), and component tokens (button-bg, input-border). This hierarchy lets me change a single primitive and have it cascade correctly through every product.
I built every component in Figma using variables rather than static styles. Colors, spacing, border radius, and typography all reference tokens. This means switching a product theme is a mode change, not a manual override. Components are responsive by default — number variables manage spacing at different breakpoints. Every component includes all interactive states and accessibility annotations.
The key architectural decision was using Figma variable modes to handle product differentiation. A shared component library provides the structure, but each product can apply its own mode — adjusting brand colors, density levels, and contextual treatments. Light and dark themes are additional modes on the same components, not separate builds. This means I maintain one component library, not five.
The Figma file is the living documentation. Every component page includes usage guidelines, variant explanations, accessibility notes, and do/don't examples. The variable structure maps directly to CSS custom properties, so developers can implement tokens as CSS variables and receive updates as design evolves. This bridge eliminated the most common handoff friction: discrepancies between the design file and the shipped product.
Figma variables were relatively new when I started this system, but I committed to a variable-first approach because it solved the core problem: one change needs to propagate everywhere. Static styles require manual updates across files. Variables cascade automatically through modes and references. The initial setup was more complex, but the maintenance cost dropped dramatically.
A flat token list does not scale. I designed a primitive > semantic > component hierarchy so that changing a brand color (primitive) automatically updates every semantic reference (text-primary, surface-accent) and every component that uses those semantics. This means product-level theming changes require editing 5-10 primitives, not 200 component overrides.
As a solo designer, I had to be ruthless about scope. I built components for patterns that appeared in 3+ products and created composition guidelines for one-off patterns. The system covers 80% of use cases with maintained components; the remaining 20% follows documented principles but stays product-specific. This keeps the system alive and evolving rather than becoming an abandoned artifact.
The iStaging Design System now serves as the single source of truth for all product design work. New products start from the system rather than from scratch, cutting initial design time significantly. The variable architecture has proven its value through multiple product launches — CURATOR and VR Maker share the same component library with product-specific theming, and the system is expanding to cover the ONE App and future products.
Building a design system solo taught me that the system is only as good as its adoption. The most beautifully architected token structure means nothing if developers cannot use it or if future designers cannot understand the decisions. I prioritized self-documenting architecture — naming conventions that explain themselves, modes that map to real product needs, and components that show their constraints through their structure. A design system is not a deliverable; it is a living conversation between design intent and implementation reality.