I started by deciding what the product genuinely needed, then built the system in code and created a practical AI workflow to keep React, Storybook and Figma in sync — without asking automation to make design decisions for us.
The decisionTurn the decisions the team repeats into foundations that are inspectable in both code and Figma.
[01.00]>Work out what was worth keeping
TAP Mindset had grown one sprint at a time. We ended up with eight kinds of card, six chips and four inputs, often doing almost the same job. Documenting a single component took 45–60 minutes, so it was understandably postponed whenever the roadmap became busy. The real system lived in people’s heads.
A full documentation pass meant more than 30 hours of repetitive work before we had even moved a feature forward. I wanted the shared route to be the easiest route — useful enough that nobody needed to create an exception just to keep working.
At that point, I decided not to design another component until I understood what we already had. I mapped the product flow by flow and inspected more than 28,000 component instances.
The numbers changed the conversation. They showed which patterns the product truly depended on, which ones were duplicates and which ones had simply survived because nobody had challenged them.
The difficult part was not creating a design system. It was making one the team could keep useful while the product continued to move.
[02.00]>Build it where the team could use it
With the audit in front of me, I decided to rebuild from the foundations up: colour, type, spacing, elevation, radius, grid and motion. AI could help later, but automating a weak rule would only spread it faster.
Then I used the evidence to reduce 55 public concepts to 38. I merged duplicates, kept the patterns the product actually relied on and retired the rest.
Once the foundations were stable, I got to work on the coded system. I turned tokens into CSS properties, design choices into TypeScript props and component behaviour into inspectable stories.
I published the implementation because I wanted the technical story to be checked, not simply believed. Tokens, React components, stories and tests live together in the same repository.
A JSON value is transformed into a CSS custom property
TypeScript props define the React component’s public options
Storybook makes states, accessibility and behaviour visible
The next decision was where the team should meet. I chose Storybook because it could show foundations, brand rules, real components and their documentation in one place.
That changed the handoff. A designer could check intent and states; an engineer could inspect the API and implementation without translating a separate specification. The repository is public, so each claim here can be followed into a working story or the code behind it.
At first, I was still treating Figma as the place where the system had to be recreated and maintained. I changed my position once the coded component became the more reliable description of what actually shipped.
So I built a TypeScript catalogue builder, a component importer and a documentation generator. The catalogue reads props, variants, booleans, slots, defaults, CSS token references and Storybook metadata. The plugins carry that structure into Figma instead of guessing from a screenshot.
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, how properties should be grouped, or when an interface needed to hug or fill. That became the boundary of the system.
[03.00]>Use AI without giving away the decisions
Only then did I bring AI into the workflow. I used it to find repetition, explore edge cases, prepare documentation and speed up implementation.
I also changed how I thought about it. The useful question was no longer ‘what can AI generate?’ but ‘which decisions are clear enough to delegate safely?’ It could extend an explicit pattern. It could not redefine foundations, change the public API or make accessibility decisions without review.
Spot repeated patterns and possible drift
Draft documentation and implementation starting points
Compare Figma, tokens and Storybook before release
Return foundation, API and accessibility decisions to a person
By the end, three product designers and two engineers were using the library in day-to-day product work. Foundations, component decisions and documentation had moved out of individual files and into places everyone could inspect and question.
It is still being used after my direct involvement. For me, that is the strongest result: the team can extend the product without needing me to return and explain the original decisions.
3 product designers · 2 engineers
Design and Engineering review changes together
The library remains part of the product workflow
I introduced a weekly Design and Engineering review, gave each layer a clear owner and added release checks for parity between tokens, Figma and Storybook. Automation could prepare the work and flag inconsistencies. A person still approved any change that affected foundations, the public API or accessibility.
The numbers were useful, but the failures taught me more. A parity check uncovered four brand scales that had quietly drifted apart. Poor context produced quick but inconsistent output. A version restore forced us to rebuild part of the consolidation. AI made good execution faster, and bad execution faster too.
Tools change. The system preserves the decisions that matter.
> MORE WORK