This is the second case study in the Scanat design system series. Part 1 covers the initial 0→1 setup and file architecture; this case focuses on re-governing the system after three years of use and carrying its Tokens and component rules into the existing front-end stack.
| Role | Design System Architecture · DesignOps · Standards & Governance · AI Agent Collaboration |
|---|---|
| Project Type | Design System Governance & Engineering Handoff |
| Platform | Web · Mobile App · iPad App |
| Users | Internal design, product, and engineering teams |
| Team | I led the governance work end to end, using Figma Agent for audits, batch cleanup, and review |
| Timeline | ~1.5 months for design-system governance, followed by ongoing engineering handoff |
| My Contribution | 1. Reworked Tokens, component properties, and layer naming; |
<aside>
</aside>
Three years after the original design system was introduced, product scope had expanded, the Web / App component libraries had grown, and Figma capabilities had changed. Historical patterns began to coexist again across naming, properties, layer structures, and the boundary between shared and business-specific components.
Over ~1.5 months, I re-governed both Web and App libraries: first standardizing foundational Tokens and naming, then auditing real components by category, with particular focus on Modal, Sheet, and Panel patterns where the shell is stable but content varies. I also formalized documentation, Agent review, and future create / update workflows. After the Figma-side cleanup, I extended the system into code by building a Token export pipeline and mapping Scanat Tokens onto the existing BootstrapVueNext stack, with Storybook / Showcase as the shared implementation reference.
After three years of continuous use, the Web / App component libraries had grown and Figma capabilities such as Variables, Properties, and Slots had evolved. Multiple historical patterns began to coexist. The main issues fell into four categories:
The governance work had to happen alongside normal product work, and I was the only person owning it. Rebuilding the library from scratch was not realistic, so the system had to support incremental migration of legacy components while setting stricter rules for everything new.
The work progressed through five stages, from Figma-side governance to engineering handoff.
I first cleaned up foundational Tokens for color, typography, radius, shadow, and spacing, while resolving obvious naming, grouping, and duplication issues. Figma Agent handled scans and batch checks, but decisions about which Tokens to keep and how to group them were based on actual product usage.
From these audits, I defined baseline rules for component names, Properties, Variant Values, and layer naming. The first version intentionally covered only the rules we could define with confidence; new edge cases were added later as they appeared in real components.
I reviewed the Web and App libraries category by category, checking whether classification still made sense, whether Variant / Property patterns were consistent, whether layers were meaningful, and whether legacy structures still fit the current product.
Figma Agent handled scanning, batch renaming, and review. Decisions about whether components should be merged or split, and where the boundary between shared and business-specific components should sit, remained product decisions based on real usage scenarios.
I further separated the system into two levels: shared Components reused across multiple product areas, and business-specific Patterns / Components that are stable within a particular workflow. The distinction was based not on visual similarity, but on how each component is reused and who is responsible for maintaining it.
Modal, Sheet, and several Panel patterns required the most restructuring. They shared a similar shell, while their business content varied significantly and often appeared across many product screens. Creating a complete component for every business case produced heavy duplication; keeping only a generic shell made business content difficult to maintain consistently. Over three years, I had tried three approaches:
| Approach | Pattern | Observed Problem |
|---|---|---|
| Attempt 1 | Create a full component for each business panel | Component count kept growing—17 panels in the Web editor alone—and shared structures gradually drifted apart |
| Attempt 2 | Merge similar large components and move variations into internal child components | Child-component count increased, while many business-specific elements could not be given clear, stable shared names |
| Attempt 3 | Keep only the shared shell and replace all content through Slots | Business content lost a shared source of truth; when the same panel appeared on dozens of screens, updates had to be copied page by page and were easy to miss |
Based on these three attempts, I adopted a layered model of shared parent component + business-specific child component + Slot. The parent maintains the stable shell, the business-specific child owns concrete content, and production UI screens reference that child component. This allows the shell and business content to evolve independently while preserving instance synchronization.
Slots are used only to connect the stable framework with replaceable content; they no longer carry responsibility for maintaining the business content itself.
After the cleanup, I added usage guidance for shared components so design and engineering could reference the same rules. I also formalized the workflow for new or modified components: classification → creation → Agent review → documentation.
Once Figma-side governance was complete, I focused on connecting the design system to production code. Engineering already used Vue + Tailwind + BootstrapVueNext and planned to keep that stack, so I did not build a parallel Vue component library. Instead, I mapped Scanat's design rules onto the existing implementation.
The first step was to establish a repeatable Token export pipeline. Using Claude Code, I extracted color, typography, spacing, radius, border, sizing, and shadow values from Figma and exported them to CSS and JSON. More than 180 Tokens are now in this pipeline.
The second step was mapping Tokens to shared components one by one. Claude Code helped inspect component structures and identify which Tokens controlled backgrounds, text, borders, radius, spacing, and states, while existing BootstrapVueNext components were used to render the actual styles.
A Token file alone was not enough for implementation, so the mapping between components and Tokens became the main deliverable. Storybook / Showcase provides a shared view of Foundations, component styles, and Token mappings for both design and engineering.
<aside> 🔗
</aside>
I validated this collaboration model before scaling it. Before the full rollout, I built a working engineering demo with a small set of Tokens and components and reviewed it with engineering. Once the direction was accepted, we agreed on responsibilities:
This model made Token binding noticeably more efficient and also pushed the implementation toward greater consistency. The front-end code had previously passed through four different engineers and accumulated mixed patterns; defining a shared Token mapping helped those patterns gradually converge.