From Figma to code: building a scalable design system
Context
An experimentation project
In this project I created a design system from scratch in Figma, then implemented it in code with MCP and Cursor’s assisted agent.
Alongside the product interface, I built the project Storybook: a visible library and source of truth for the team, with technical documentation for components and tokens.
The aim is to shorten the distance between Figma and code, and to make the product easier to evolve — in speed and consistency — as new needs appear.
Goal
Build an AI-ready design system from scratch
The goal is an automated system that can generate new product interfaces and features, so the product can scale quickly.
The challenge is writing the documentation the generated code needs in order to follow the same instructions and processes, and produce consistent results.
Research
Understanding the product
Wellness Stay is a fictional marketplace for booking wellness retreats. I started by analyzing travel and wellness platforms already on the market. I looked at retreat-booking flows and common UI patterns, and I collected competitors’ visual styles in order to choose a distinctive direction.
User task flow
I mapped the task flow to understand the path people take: the screens they move through from landing on the platform, using search, getting results, opening a retreat page, and completing a booking.
Visual references
Before setting the design foundations, I gathered visual references to understand typical marketplace UI patterns and define a visual style.
Design system
Creating the design foundations in Figma
I started with the foundations, the core visual elements of the interface: color, typography, icons, grids, spacing (margins and padding), corner radii, and border weight.
Custom components in Figma
To build a distinctive, purpose-built interface, I designed the components that accommodation marketplaces share: search, cards, filters, buttons, navigation, and so on. The system should not invent components arbitrarily when new screens are generated, and the set should cover the cases the product needs.
Components that were not anticipated should be added through the same flow: Figma -> MCP -> Storybook -> Interface
Style variables — tokens — in Figma
I defined a basic token architecture so design and development would share the same language. Primitive tokens were the base for the rest: semantic tokens for common interface elements — borders, surfaces, backgrounds, and so on — and component tokens for specific components.
Implementation in the IDE
Technical documentation for AI and for the team
At this point I created the local project folder to bring in the documentation, generate the code, and validate the design system in a real environment. I did not use a framework. I implemented it in HTML, CSS, and JavaScript with the elements I had already designed.
For an AI to generate coherent interfaces, access to the Figma components is not enough. It also needs the system’s context, usage rules, and constraints. I wrote those instructions in Markdown with ChatGPT — AGENTS.md and SKILLS.md — and added them to the project folder.
The next step was a README.md for the project, explaining what the project is.
Writing component code with MCP and generating Storybook
Once the IDE context, the instructions, and the code-generation process were in place, I implemented the Figma tokens and components in code through MCP.
In parallel with the component code, I generated the Storybook that stores the interface elements. It can be updated later as the product’s requirements change.
Development
Automated generation of the marketplace screens
Finally, I wrote specific prompts to generate the home sections:
- Navigation
- Hero section (search and h1)
- Featured
- Main categories
- Newsletter
- Footer
Conclusion
What I learned from the project.
This project let me treat the design system as product infrastructure that connects design, development, and scale, rather than as a collection of components.
AI sped up the design-to-code process, and it also reinforced a key lesson: speed is only useful when there is a defined architecture, clear rules, and design judgment behind it. In a real context, the next step would be to validate the hypotheses with users and evolve the system from the product’s actual needs.