We’re thinking along similar lines here, but I am always very leery of centralizing workflows and source-of-truth around a closed-source 3rd party tool (Figma) with no real offboarding story.
The process of transitioning our design system at Heroku from Slack to Figma took an incredibly long time due to lack of prioritization (“don’t we already have a design system?”) and a constantly moving target (so rude to keep shipping and evolving the product, right?)
My top design system principle these days is “code as source of truth”. This works OK for tokens, it’s an immense challenge for components. The guys at <div>RIOTS have put together some really interesting tools though, like html.to.design to vectorize browser screens into Figma, and story.to.design to pull in whole components and map story props to variants. We’re going to be investigating these in the PayPal merchant design org over the coming months to let us shift the role of Figma more toward rapid, ephemeral design exploration, and away from acting as a “second source of truth” that needs constant two-way syncing with the live code base.
LOL that confused me for a second! Yes, I agree with you. I'm thinking in increments of years, 2-5 years out. I think Figma is a great tool, but that is all it is - a tool. And I think we need to embrace what the source of truth has always been: code.
I think that we can create tools that will communicate better with code to tooling and help designers write code or "paint" in code, and I don't think Figma is the end all be all.
It sounds like with automation we might lock in a model that needs repeating over time, which can be important, but then I have noticed stakeholders become risk-averse when we deviate from the model. I look for flexible components that can allow designers to implement various layouts (which CSS lets us do flexibly once JS is nailed down).
I appreciate this thought direction! I think it can help prove the business value of design to stakeholders. I remain a fan of Zeplin for preserving the human element with documentation, and it can be integrated with Storybook for live code updates. It also pings Slack for updates (similar to your GitHub integration, which also sounds powerful)
We’re thinking along similar lines here, but I am always very leery of centralizing workflows and source-of-truth around a closed-source 3rd party tool (Figma) with no real offboarding story.
The process of transitioning our design system at Heroku from Slack to Figma took an incredibly long time due to lack of prioritization (“don’t we already have a design system?”) and a constantly moving target (so rude to keep shipping and evolving the product, right?)
My top design system principle these days is “code as source of truth”. This works OK for tokens, it’s an immense challenge for components. The guys at <div>RIOTS have put together some really interesting tools though, like html.to.design to vectorize browser screens into Figma, and story.to.design to pull in whole components and map story props to variants. We’re going to be investigating these in the PayPal merchant design org over the coming months to let us shift the role of Figma more toward rapid, ephemeral design exploration, and away from acting as a “second source of truth” that needs constant two-way syncing with the live code base.
Slack to Figma? Obviously I meant Sketch to Figma. Have another coffee, Geordie
LOL that confused me for a second! Yes, I agree with you. I'm thinking in increments of years, 2-5 years out. I think Figma is a great tool, but that is all it is - a tool. And I think we need to embrace what the source of truth has always been: code.
I think that we can create tools that will communicate better with code to tooling and help designers write code or "paint" in code, and I don't think Figma is the end all be all.
It sounds like with automation we might lock in a model that needs repeating over time, which can be important, but then I have noticed stakeholders become risk-averse when we deviate from the model. I look for flexible components that can allow designers to implement various layouts (which CSS lets us do flexibly once JS is nailed down).
I appreciate this thought direction! I think it can help prove the business value of design to stakeholders. I remain a fan of Zeplin for preserving the human element with documentation, and it can be integrated with Storybook for live code updates. It also pings Slack for updates (similar to your GitHub integration, which also sounds powerful)
Love this feedback Omar! Thank you
100% onboard with everything you say here.