An LLM-safe design system for a company with no staff designers
Bibel TV has no staff designers; product managers and product owners shape new features. I’m building a path that lets them prototype with Claude against real Storybook components, then surfaces the component, view and token changes needed for reviewable pull requests.
The system could not depend on Figma expertise
Bibel TV has no on-staff designers, so product managers and product owners shape new features and interface changes without a designer sitting beside them. They have limited Figma skills, and teaching them to maintain and extend a component and token system in Figma is neither realistic nor the best use of their role.
View full size ↗ The shared surface. Thirty components, theme and device switching, and a per-component token report, so someone who didn't build the system can still find and use the right part of it.
The real bottleneck was moving from feature intent to production-safe design-system changes. A prototype might need an existing component, a modified component, a new view, a new token, or a component or view alias. Without a guided path, a plausible Claude result could invent a token or hardcode a value and still compile and render.
The design problem was therefore larger than documentation: Storybook had to become the inspectable source of truth, Claude had to work inside a closed vocabulary, and missing system capabilities had to become explicit work that could move into Storybook and the token API as a pull request.
One path from feature idea to pull request
-
Start from the live system
Storybook exposes the real components across light and dark themes and phone-to-TV sizes, so product managers and product owners can inspect what already exists without first mastering the Figma library.
-
Prototype inside the system
Claude works from the valid token vocabulary instead of recalling names. Six checks run locally and in CI, rejecting nonexistent references and values written directly into a component.
-
Turn missing pieces into system work
The productionalization path is designed to identify the components, views and token changes a prototype requires, including new component or view aliases, and carry those changes into Storybook and the token API as reviewable pull requests.
The production rails are already live
- System reference
- Figma skills and documentation were the practical gateway Storybook exposes real components, themes, devices and token use
- Enforcement
- A written convention, dependent on someone noticing in review Six checks refuse off-system work locally and in CI
Want to hear more?
- How did a perfect twelve-pixel match become the wrong token?
- Why did I ask an independent reviewer to try to disprove every audit finding?
- Why did Storybook, not Figma, have to become the source of truth?