Anybody have best practices on migrating figma mocks to Plasmic?
Hi @original_bobcat - just chiming in in case you haven’t seen this yet, we have a few layout best practices here: https://docs.plasmic.app/learn/importing-from-figma
Hey @yang thanks for this. I spoke with our design team and looks like we’ve already attempted to use this tool. It seems like it mostly satisfies our use-case but, the one thing it doesn’t do is copy over components from Figma to Plasmic.
As a result, designers are effectively asked to (a) work in Figma (b) import to Plasmic and (c) recreate components in Plasmic. This workflow creates double work for designers, and exposes surface area that Plasmic and Figma could get out of sync.
In a perfect world, Plasmic Studio would have all the functionality of Figma, and maybe we’ll eventually get there. Until that point, I think finding a wedge to get designers to still work in Figma but copy over their components would really help us adopt the platform more comprehensively.
Any thoughts on if (or when) copying components could be possible? Thanks!
cc/ @ray
Thank you for the feedback.
Translating Figma’s component abstractions to ones that developers would want to use is the main challenge. It’s not something we’re 100% sure is do-able, even assuming the components were crafted with full awareness—which we find is rarely the case; usually Figma components are very far off. We have further research here we’d like to do, but it will likely take us time to get there.
interesting. fwiw, I’m confident that a component with no props would suffice.
The challenge for us is not so much that the developer would not want to use it, but that the designer would need to recreate it. This is notable, because the changes to the component, when imported, should ripple to all usages. That’s the behavior we want to preserve.
As far as exposing developer-friendly props or slots, that’s something we can decouple from our use-case. So long as the component relationship is maintained, we are happy to leverage Plasmic as the source-of-truth for slots and props on those imported components
Not sure if that comes through intuitively through text- does the distinction make sense to you?
Yes, I think so! I’m reading that as, you’re not needing heavy developer instrumentation/interaction with the components (you just want to save time for designers in making these one-time translations from Figma into Plasmic components)—is that right?
100000%
and, after syncing internally, I can say pretty unequivocally that this changes the shape of a Plasmic integration from “an experiment for just one of our web properties” to “something we could actually grow across all of our web stack”
I would even perhaps reframe it from “saving designers time” to more accurately “meeting their expectations for importing components”.
rationale: It’s not a huge amount of time for small sites, but it’s the sunk cost of developing a component library in figma only to have it blasted away on import.
Really hard to create a unidirectional workflow that originates in Figma without such support.
If Plasmic could up-prioritize the very basic form of this concept, we could dedicate resources on our side (probably me) to support validating the effort. Perhaps even contribute if the importer is OSS.
just bumping to make sure y’all see my last few notes. thanks!
yep! absolutely. I’m curious if components with no props is the only abstraction that you guys need?
And I’m also curious if you can expand on the use cases for this? e.g. in the case of the careers page, where you guys need to wire up to Lever, which parts of the page would you want to keep as components in Figma?
the use case is scaling the design team, effectively. Each designer we onboard, we’d expect to only know Figma.
So, assume that they jump into our design system (currently in Figma), and make edits. These edits are reflected in Figma “components”, which would of course be expected to propagate across our web apps once imported into plasmic.
However, Plasmic drops any component designations from Figma, forcing the designer to redeclare the imported elements as components, and then re-associate the components to each downstream Plasmic app.
Ideally, upon import from Figma, Plasmic recognizes the components and preserves their special status. Then, once imported, designers can use Plasmic to define props on those components, if required. Subsequent imports would effectively replace the component in-place, though ideally previously defined props would remain.
This allows for a unidirectional workflow for designers, allowing Figma to remain the source of truth, and allowing us to scale our design team until which point Plasmic’s feature set is at parity with Figma’s.
Hi, it’s me again. Implementor-in-residence. Any chance y’all have had a chance to discuss this internally?
Hi Jon, sorry I was OOO yesterday.
We are really interested in improving the workflows between Figma and Plasmic. The importer at the moment is a simple one-way copy/paste. To be able to paste in-place preserving changes, as I’m sure you can imagine, is a really hard challenge. It amounts to keeping some state between Figma and Plasmic in sync, as users might make arbitrary changes on either side. Furthermore, the data models also change on both sides as both products continue to evolve as well.
I agree with you that this would be an amazing goal for our Figma importer. If there are shorter-term improvements we can help you guys with, maybe we can arrange a quick call to discuss would unblock you in the short term.
@ray agreed with what you mentioned, Importing with preserving states and even sync between both figma and plasmic will really uplift the whole plasmic platform. Every company will be easily able to scale with plasmic and designers will not have to re-do all the work again. 
Would love to see this very soon, if possible 