Design Systems as Prompts, Part 2: Testing the System in Storybook

Exploring whether AI performs better when the design system moves from visual components in Figma to coded components in Storybook.

I started off with building the storybook locally with Claude and they hook up the entire thing pretty well. For the sake of this experiment, I install it with A11Y and Vitest only and leave out Chromatic.

The ContentBlock button was imported wrongly but generally i like how everything aligns with the variables and I don’t have to worry it’s wrong setup. Once it hits the code part, i can easily adjust according to what i need and it adhere to the spacing variables. In this example, i simply setup the mobile variant as needed with a prompt.

Expanding the existing Figma components on Storybook, this helps to reduce the back and forth needed on my Figma - Storybook setup.

I also tried expanding or creating a new hero marketing section where it uses the basic components and foundation to build a new section. I think now with AI it’s almost instant that you can get a new layout section in a matter of time with props and instances setup.

Here’s the Hero Section.

With AI, building components are so easily done. I think what we really need in this AI age of component building and design system maintenance is a careful pair of eyes and governance. Governance in the sense of what goes in and what goes out. It’s easy to be absorb into the daily build but missing out on what really serves the users of the DS - designers, engineers, stakeholders, and end user.

Building it back to Figma

Since a big problem is always about aligning Figma to Code and vice-versa, with AI now, will it be possible. I am testing it out.

When we shift back into Figma, the problem aroused again. From the various testing, i think having the Figma MCP server is not sufficient or rather the API end points are not sufficient. The chances of making mistake on Figma is way higher than on the actual Storybook.

After running it with my same skills as a base and adjusting the prompt, the component finally came back nicely. Thus, closing the loop between code and design.

Conclusion

I would say that a workflow for any designers who need to handle both the Figma and Storybook (common in startups or 0-1 space), start with the Figma first and ensure you have strong foundation setup. This means all UI components ready. Then move to Storybook to expand on your component variables, test the accessibility, improve on the components and bring it back to Figma manually instead.

Having skills that builds upon your design system is also very useful to hitched on the existing Figma MCP skills and server.

With all of these in mind, i think it’s getting easier and easier to create a design system that you can own. As a designer, if you are in the Org, it’s also easier to now contribute to the system. The question then is who will be governing it and what we can do build such governance.

Running a storybook of code document is easier than it seems but often time, it’s easier said than done. I think the biggest struggle of any design system personnel will always be the human aspect: how to convince and sell your idea, and rally people together towards a common goal.

I share a deeper reflection on what I think about this entire AI workflow in Part 3. Read more there!