I’m working on something I think the WeWeb community needs: a free, open-source Figma design system built specifically for WeWeb developers—following WeWeb conventions, naming standards, and the Figma import plugin spec.
The Problem
The jump from design to WeWeb implementation is still friction-heavy. Designers hand off Figma files. Developers rebuild components. Design tokens don’t sync. Property naming doesn’t align. Variants get lost in translation.
The Solution
A production-ready design system that:
Uses WeWeb-native naming conventions and component architecture
Integrates seamlessly with the WeWeb Figma import plugin
Ships with Auto Layout and responsive design principles built-in
Provides component variants and props that map directly to WeWeb
Stays 100% free and community-owned
What We’re Building
Figma library with semantic tokens, component variants, and design-to-code alignment
Documentation on syncing Figma to WeWeb without loss of intent
Best practices for naming, hierarchy, and responsive design
A template showing how to adapt existing WeWeb component libraries into this system
What We Need
WeWeb developers (especially experienced ones): Help us understand your pain points and validate the component/prop structure
A skilled WeWeb developer: To build the proof-of-concept template and show how Figma designs sync into working WeWeb components
Community feedback: What would make your design to code workflow actually seamless?
This Isn’t About Rebuilding
We’re not creating new components from scratch. We’re creating a bridge—a design system that respects how WeWeb developers actually work, with sensible defaults that adapt community-standard components.
If you’ve felt the friction moving from Figma to WeWeb, or you’ve built workarounds to keep designs and code in sync, I’d love to hear from you. What’s your biggest bottleneck?
Interested in collaborating or providing feedback?
I think there are lots of different ways people go from mockups to WeWeb depending on profiles and philosophy. To me the difficulty is not so much syncing designs to WeWeb but rather going faster in rebuilding components and tokens in WeWeb.
So my idea is to create a solid base that can easily be modified. I’m currently working on my own design system, based on Shadcn/Tailwind (theme and components). What I like about it is that this system is pretty minimalist and versatile. What’s hard on building it, is to sort out what’s relevant in a tool like WeWeb. And also there are a lot of built-in behavior on the component that are not easily achievable in WeWeb without custom components.
I’m not too sure about relying on the Figma to WeWeb plugin as it’s built today. From my experience, it creates lots of unnecessary css props and unexpected behaviors. But in that same spirit you described, I’ve also made use of the Figma import to create a library of components ready to use which are basically cleaned up versions.
What I essentially expect from mockups is that the designer used consistent spacing and styling.
So I should focus on a solid design system in Figma that’s easily replicated in WeWeb?
One of the major decisions I had to make is how I handle my color tokens without making it a mess, since WeWeb does not have variable aliasing. I have focused on using only semantic token naming, but as the token base has become much larger as the design system increased in size, it becomes stressful selecting tokens inside of WeWeb. Because of that, I adapted Chakra’s semantic color naming. How do you approach these limitations?
I mean, any proper DS in Figma would be easily replicated in WeWeb. And to me, what’s longer is the initial build process
It makes sense to handle the color tokens in Figma, and exporting the final semantic tokens to WeWeb though. I’d love to see the day where we can natively use css variables and bind them to css props.
I’m also used to using semantic color tokens like Chakra’s which was sufficient so far. I guess projects I’ve worked on were not that complex.
and bind them to css props.