TAP Mindset Design System & AI Workflow /

The premise

I built a design system that connected Figma and code, then used AI-assisted tools to reduce maintenance without turning automation into another system to maintain.

Case study index

The problem worth solving

The visible issue was inconsistency. The consequential one was maintenance.

The system was not failing because components were missing.

TAP Mindset started as an MVP. Every sprint added flows, features and decisions. But documenting one component took 45–60 minutes, and that time always lost against the roadmap.

Knowledge lived in people, not in the system.

Maintenance was consuming roadmap capacity, not just design time.

A component could take 45–60 minutes to document and reconcile across Figma and code. At product scale, the hidden cost was slower delivery and less confidence in every reuse decision.

Design

Repeated documentation and manual parity checks

Engineering

Multiple interpretations of the same component contract

Product

Roadmap time spent resolving system debt

The audit

Not designing. Counting.

I mapped every flow and audited 28,000+ component instances. That exposed which patterns were load-bearing, which were duplicates and which existed for no reason at all.

28,000+Instances audited

30+ hRepeat documentation

4Drifting brand scales

The reframe

The problem was never building the design system. It was maintaining it without slowing the product down.

The system needed to reduce the cost of decisions and documentation — not become a parallel product competing with the roadmap.

The system & the bet

Establish a source of truth, reduce what the team had to maintain, then close the loop between code and design.

The source of truth

Foundations by hand. Components from evidence.

I designed color, type, spacing, elevation, radius, grid and motion without AI. Usage data then shaped the component layer.

I reduced the public API from 55 concepts to 38 — merging duplicates, promoting real patterns and archiving what nobody used.

A source of truth the team could inspect, use and challenge.

Storybook made the system tangible: foundations, brand rules and production components lived together, with implementation and documentation in the same place.

Code component importer

Reads code and rebuilds its structure in Figma.

Once code became the source of truth, manual syncing had an expiry date.

Watch the coded component become a structured, editable Figma component.

Document generator

Clones a master template and generates the full doc page.

Documentation went from a repeated production task to a review task.

Watch the plugin populate the master template with variants, properties and usage guidance.

Code describes what. Judgment decides how.

The plugins carried structure, not judgment. Code could expose variants, slots and tokens; it could not decide whether a pattern should be one component or five. That boundary kept automation useful without outsourcing system decisions.

What it cost, what it taught

The measurable gains mattered. So did the failures.

AI accelerated execution — and mistakes — with equal efficiency.

The parity audit exposed four brand scales that had silently drifted apart. Weak context produced fast but inconsistent output. A version restore forced part of the consolidation to be rebuilt.

55 → 38Component concepts

45 → <2 minDocumentation time

4Brand scales reconciled

The system needed owners, review gates and a clear boundary for automation.

I established weekly reviews with Design and Engineering, assigned ownership by layer and introduced release checks for token, Figma and Storybook parity.

Token drift

Four brand scales had silently diverged.

Weak context

Fast output amplified inconsistent assumptions.

Version restore

Part of the consolidation had to be rebuilt.

The goal was never consistency. It was continuity.

Tools will change. Judgment remains.

What this was actually about

The goal was never consistency. It was continuity.