Emil from Figma here! We have made a ton of improvements to the generated CSS code, and while we still sometimes provide absolute positioning we now separate it from the styling & flexbox code that you might actually want to pull into your codebase.
We've also introduced an API extension point so third parties can now provide their own implementation of code snippers (code generation) in Figma's Dev Mode which Anima and a few other partners have already released plugins for :)
Seems interesting, and admittedly I might have missed this, but grabbing icons as individual SVGs is probably what takes me the longest when going from design to code. I have to click on each asset, name it properly, and then export it. Over, and over again. All from different layers, and pages.
If there was some sort of asset export that obeyed some spec on how to size and file name that’d save hours and hours of work.
Outside of that, I’m probably not ever going to use generated code enough for it to be a game changer. Most of the time you’re having to fit some design into an existing design system, and so I don’t really see the use case for code export at scale.
There is 100% that. Any frame can have an 'export' set on it, where you specificy the format (svg, png ..), suffix, pixel density etc. The name will be set by the name of the frame, and '/' creates nested folders. Then on any page can go file->export to export all assets at once.
But if you're using some icon library that a designer has imported into figma like remix-icon, just import from the library directly in code. Importing and rexporting the svg would likely change it slightly.
I would also love to be able to select an arbitrary set of components and export them as a single SVG.
Often, the way the designer has grouped them together is not ideal for code, but I don't want to ungroup and group them all over again just so I can grab an SVG.
As a designer, all my icons are symbols and you can find the symbol artboard on another page with all the icons sized consistently with consistent naming conventions. You can select all and export as you please. Nothing drives me crazier than icons that are not properly formatted in both size and name.
This is one of the reason we built Specify (specifyapp.com) which is a Design API that helps you sync design tokens and assets from Figma to any platforms.
For instance, let's say you're a React developer. Designers set their layers as exportable in SVG, and Specify can automatically export the SVG string, optimize it with SVGO, set the end filename, and generate a JSX component for React - automatically. Here's a short video that should help you understand the whole process (https://youtu.be/Z7fX0v3KFmY?t=353).
You basically just have to configure Specify once, and every time designers update icons in Figma you'll get automated pull requests with icons transformed exactly how you want.
It's free for all paid plans even after 2023. The only pricing change is that you can add "developer" role users who have access only to dev mode for a cheaper price than an editor.
Right, but the pitch previously was that you paid for designers, and everyone else can view for free. Now it looks like they're locking all future view-only features behind a paywall.
I’m also really happy they didn’t pounce on the AI bandwagon before figuring out the right thing to make. At the same time, I’m excited about the Diagram acquisition to jump-start whatever they’re going to build!
Hey all! Emil here from the Figma team that brought you Dev Mode and Figma for VS Code today! Really interested to hear what you think and also here to answer your questions. We are super excited to invest more into developers in the future, today is just the start of that!
I've been experimenting with using LLMs to map Figma designs directly into a working production-level codebase. There's quite a bit of compression you need to do in order to convert the raw Figma JSON into a format that an LLM can understand, but overall it actually performs quite well. Here's a quick demo: https://www.youtube.com/watch?v=s9JRBw7kR9g
This is one of the reason we built Specify (specifyapp.com) which is a Design API that helps you sync design tokens and assets from Figma to any platforms and formats.
Specify helps you get automated pull requests containing your design tokens and assets defined in Figma.
You basically just have to configure Specify once, and every time designers update colors in Figma you'll get automated pull requests with colors transformed exactly how you want.
Hi Emil. My question is about the prototyping. The proto tooling is improving but still pretty limited. Right now the approach seems somewhat disjointed, meaning some interactions utilize variants for state change, while others work across frames with the "onclick" interaction. But that could get really messy as this grows. Question: have you considered using a "dynamic panel" approach similar to what Axure does? That model was my favorite among the proto leaders.
Does figma have an external bug tracker. While developing a figma plugin I ran into a CSP issue for loading UI web workers as blobs. Not sure if I should go through standard figma support channels or is there a dedicated channel for plugin developers.
Hey, Akbar here (Dev Advocate for Figma). We have the Friends of Figma discord that has dedicated channels for plugin developers - https://discord.gg/xzQhe2Vcvx. When you join - get the @Developers role in #interest-roles and @Developer Announcements in # general-roles if you want to talk plugin development!
Myself and a ton of other devs & designers need the ability to run plugins without having to select them from a menu first. For ex: Run a plugin when a design is opened, or when Figma launches.
As a developer consuming design files in Figma on a regular basis something that bugs me often is not being able to drop images into comments.
For a tool designed for visual collaboration it feels like a sizeable oversight that for me at least hinders workflow pushing me into other tools rather than keeping conversation contained alongside the files being discussed. Any plans in this area?
Tip to future folks who jump on HN after releasing something: don't announce that you're here to answer questions and then answer only 2 questions (as of 5 hours after Emil's comment was posted).
Interesting, looks promising. I wonder what the status of the Adobe-Figma merger is. Personally, I hope it gets blocked to avoid more dominancy of Adobe
Unimaginative leadership that didn't trust their teams. Prototyping the 'experience' (mostly happy path) in a design tool, gave them 'visibility' into what the product could become.
Yup. This is far from new. Used to be getting a zip file full of low quality photoshop exports and you would have better luck pulling teeth out of a cranky tiger(1) than getting proper assets (or the raw files) out of the art team.
My favorite was the PowerPoint presentation. Didn’t happen to me but I’ve heard about it.
1: Somewhat redundant. Any tiger you try to get teeth out is likely to be cranky before you finish the retrieval.
Yes, similar to the photoshop days. I forgot all about those. Has been almost 10yr since I had that happen!
PPT doesn't bother me because it's very "what we need" not "how we need it" so I don't have to worry about the specifics and instead can focus on (and ask questions about) the intent of the feature.
I think you misunderstood. It was a powerpoint with images in it, not a wireframe. It show how site navigation worked, which was a huge improvement... minus having to dig the images out one at a time. :D
At least they didn't use document links with absolute paths. Macs don't have have a C:\Documents and Settings\Clueless\ folder. Encountered that a few times in my career.
i would consider even powerpoint lucky compared to an excel file with a bunch of images or even the design being made out of cells, rows and columns... yes, you read that correctly lol.
for all that trouble it still beats getting `design.jpg`
What's worse is treating engineers like "just implement the mockup eyeroll" but then the logic of the mockup makes no sense with real data or product.
I'd rather have a napkin sketch that we can work on together vs throwing pictures over the wall.
As impressive as it is, I feel like Figma makes this situation worse. It's like "see we've figured it all out devs, look how nice this looks. No discussion needed"
I feel like that might be an organizational problem. At my company the designers will present their figma designs to engineering and we'll have a meeting to go through them and bring up concerns with exactly those sorts of issues e.g. "This list may actually have hundreds of entries in practice, are bullet points still right?". Then we iterate.
In my experience, it is a serious problem when product people do not understand how their product actually works, even when treated as a black box with observable external behaviors and interfaces.
They knew how the product worked (they used the product) they just did not interact with devs - so they didn't really get the implementation. Their only opinions there were formed from leadership who was very biased with what they wanted to express.
Took me years to finally push this culture. The designers no longer try to get away with designs that are too difficult (read: pricey) to achieve, and developers have to keep their skills sharp resulting in less blame and a more competent skillset. Then the designers and developers who thought it was part of the culture to never work together nicely were immediately noticed and shown the door.
they always use text that is ideally sized in mock-ups but completely falls over when real data is used in a responsive web app.
My favorite is when design adds data to a mock-up that we don't actually have. My company is, admittedly, a bit of a joke.
Also up there: design giving us mock-ups that are a composite of shit that needs done today and future shit they still haven't decided on. And then demand review approvals. No. You can't have it both ways you fucking morons. Either give me exactly what needs to be done, or you get no review rights. I'm not going to sit here for three weeks of back-and-forth while you play hunt-the-pixel and giving me hell for not matching the fog in your own head.
That's my favorite - if you mention responsive or how things should wrap or cascade you get the blank stares or "we aren't solving for mobile right now"
That's one of the few things done right at my previous consulting gig. They were mobile first, and didn't even start putting up a desktop web version until they had the core functions of mobile working they way they wanted.
My favorite is when the designer doesn’t have a good idea of what’s feasible to implement on the target platform and just designs whatever, leading to a boatload wasted time.
Don’t get me wrong, I have a ton of respect for good designers, but the best designers are those with a slight technical lean who are willing to design around e.g. built in customization on UIKit widgets instead of full wheel reinvention everywhere.
One of my favorites was when a designer decided to use a grid system completely independent of what was going to be used in development. No time left to redesign, so the designers had to live with whatever the devs could make happen in the time allotted.
Yes, absolutely, and it's among the worst ways to develop software. Designers kept coming up with controls that required coding custom behavior not already provided by the toolkit, either by modifying and extending components or creating new ones from scratch. Designers blamed developers for causing "rework" when it was found that the design included things that didn't exist, and developers took the blame when it took longer to implement the mocks than designers had led project leadership to believe. The lead designer's solution was to more-or-less abandon the team's pretense of being agile and get everything completely frozen well in advance of any coding.
Also, the backend was horrific, as might be expected when leadership treated it as an afterthought. I got the impression that because the system was built to replace an existing front end, leadership believed that it was just matter of wiring the UI up to the services that already existed. Some very legacy services, think mainframe-era fronted by a thin SOAP-to-json layer. Yeah and some of the backend services that turned out to be required didn't even exist.
I'm glad I'm done with that consulting gig. It was not fun, it wasn't challenging, it was just a grind, and if it is complete and they are able to turn off the existing front end on schedule I'll be shocked, and I'd want to know what kind of dumpster fire they end up with.
Yes, I had a freelance client for a website like this somewhat recently. The best part was whenever we had to spend extra time to make something look right, I was told that "it should be fast and easy, just follow the figma exactly" - which of course, did not work, because css does not render in browsers the way the figma designer looks.
Yes, and this made me hate Figma. Literally my only interactions with it have been getting dropped into some file with dozens of screens and maybe if I'm lucky they've zoomed it to the thing I'm implementing. I have no idea how its supposed to work but that was awful.
Yes, I find frequently it's hard to know exactly what people are linking me to. Usually it's to some arbitrary view in a file. Our designers have had to make their own bespoke, inconsistent labeling systems (literally dropping text elements around the designs to describe them). There needs to be a better way.
If you want a figma, I'd prefer if you worked with a dev before making it, then also worked with them after making it, to get on the same page.
Creating a design out of whole cloth and handing it over to a dev, with minimal interaction, seems lazy.
The problem isn't figma - it is how it is being used. I do think that figma is super super overkill, as if you pick a good design kit what's the point? Lots of wasted time.
I don't see the point of doing all the extra work, when in reality a wireframe works better in most cases (doesn't set you up for the "why doesn't it look like the figma" responses)
If you click the link in the errors it tells you what they mean.
- "Text content does not match server-rendered HTML."
- "Hydration failed because the initial UI does not match what was rendered on the server."
- "There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering."
None of these should impact the videos, though, because the fallback (client-side rendering) should work too. So if that's causing the issue, it's because there's a larger problem enabling it.
I'd love to have been a fly on the wall during the planning and development of this deadline-driven functionality. How many compromises were made to hit the conference date? What was left out? How much overtime or death march work did the team suffer? Did the team eat their own dog food?
That's awesome! Thanks for sharing. I'll definitely use that from now on, great work.
One thing I noticed after creating a simple button component was that it does not export the font family of the text within but that might be a Figma limitation.
I just want to be able to download the original, full quality, uncropped version of an image. And to have built-in options for compressing images.
Also I hope dev mode prevents designers from locking/hiding elements and layers, which makes it very difficult to export the elements you actually need.
You can, actually. See "Mac-only license" in their pricing [0]. Just as before, you get one year of updates.
True, when Sketch started switching to a subscription model, they've buried the link to renew the license very deep so it was really hard to find, but I guess they've came back to their senses and it is now available right on the pricing page.
This must be very recent. I was looking at their marketing collateral in May, and it was simply no longer an option at all to buy a Mac-only license. You could only renew at the time.
I realize you specified "built-in" but just in case you weren't aware, plugins exist to download ("Export Original Images") and compress ("Downsize") images in Figma, and both work well.
Really looking forward to this progressing to automatic React component generation and onto bidirectional sync; prompting automatic pull requests on Figma changes for affected components.
I find that there are few tasks in software development more uninteresting than converting Figma designs into React components. The day I no longer have to do that will be a great day indeed :)
I'm going to have to look into this because while that sounds like an incredible future, I don't see it. we have thousands of custom classes and dozens of material themes, can Figma work with that and then generate a component using our core custom styles?...
Tailwind simplifies part of that problem since you don't need to map to the myriad of custom class names in use, rather you solely need to preprocess off the tailwind config.
Companies like Bifrost (YC W22) are working on this problem and already automatically generate React components from Figma autolayout designs.
As a designer who was a front end developer in previous roles, I am very excited about both Dev Mode and the addition of variables, expressions, and conditional logic.
I remember making very complex prototypes with choices represented as branching sequences of nearly identical frames, and thinking "if I could set a variable and just show or hide some layer based on that variable, my life would be so much easier", so I'm happy y'all added this. It must have been a ton of work to implement this by you and your team, so good on you for doing it.
I ran a design team, and many really struggled with Sketch -> Figma transition, and took a long time.
I welcome many of the new features. It's great for designers who are more technically oriented, though enterable input fields would be nice.
I do wonder how non-technical designers are going to feel. The learning curve is definitely going higher.
I'm worried about the rather pricey per / seat cost. There are far more developers than engineers at most organizations, and this is really going to hurt the licensing cost. Definitely Adobe bean counters flexing its muscle.
"how would this impact them? just use figma as usual i would assume"
Since designers share files, whether at the same time, or at later date, if you have someone on the team who is fully taking advantage of all the features, like the new variables, conditional logics, etc.., and you're not quite up to speed, you may not be able to do your job effectively or may mess up what others have done.
Understanding abstractions / reference / inheritance is a skill that developers take for granted. But for non-technical folks, it takes time. Many struggle for a very long time.
Designing a user interface of all things is a technical job, and non-technical folks who are asked to do that should probably study those things to do their jobs well.
I doubt it's adobe flexing its muscle, afaik, the DOJ is still looking into the Adobe/Figma merger. Currently Figma and Adobe are operating independently.
One under-appreciated effect of the announcement last year has been the attention and resources that have been directed toward Figma's upstart, open-source competitor Penpot. I tried Penpot back in the fall, and while it was impressive for an open-source tool, I definitely didn't see it challenging Figma anytime soon.
Fast-forward nine months, and Penpot has a boatload of new features as well as its own conference coming up in a few days. I tried it again recently, and it had come much further than I expected: not only have they implemented auto-layout (Figma's original killer feature, in my view), but with the added benefit of wrapping auto-layouts. They even announced a new roadmap item of grid auto-layout.
I loaded up a tutorial file and my enthusiasm was dampened a bit seeing how a complex document impacted performance – Penpot still has a long ways to go to match Figma there – but as a viable Figma competitor, I think Penpot might actually have a chance now. It's telling that even as Figma races ahead with this new release, there is one feature (auto-layout wrap) that Penpot got to first.
The funny thing would be if Penpot's rise, spurred by the threat of Adobe dominance, actually results in regulators giving Adobe the green light to complete its acquisition of Figma. Still, if this market becomes a healthy competition like Blender / Maya, everyone will win.
> though enterable input fields would be nice.
So funny you say this. I could actually not believe that you really need to use another tool like protopie on top of figma if you need that simple functionality eg. for a mock-up.
Fairly sure they mistyped, and "engineers" should be "designers". Otherwise that is indeed a very confusing statement.
There's usually multiple developers/engineers for every designer on a team, so bringing them in to the product with features that require full privileges would certainly be a lucrative move for Figma.
As an engineer at a large company whose moonlighted as a designer it's felt like a huge win.
It's now way easier to both stop designers from adding one-off design and interaction patterns that confuse users and to write truly reusable components that allow us to iterate faster as a company while maintaining a high level of visual consistency and polish. That's a big challenge once you start hitting org sizes in the hundreds or thousands.
But I still empathize with those designers. It's mechanized design which to some feel like a prison for their creativity. Even more so when all designs start to look the same across companies, and then there's AI design still to come.
What you emphasize, speed/productivity, is indeed the credo of our world, but that doesn't necessarily align with the goal of design. Take Apple, they don't seem to care about speed or continuous delivery at all, yet are widely celebrated for design excellence.
Likewise, "consistency" does not mean you found the optimal design. Even Google admitted that Material Design was a poor choice for some of their (internal) products and couldn't make it fit.
> Take Apple, they don't seem to care about speed or continuous delivery at all, yet are widely celebrated for design excellence.
For a large software product to be designed well I think you need at least the following four things organizationally:
1. Talented people
2. A collaborative culture that allow those people to argue their position
3. Leadership that believes in good design and is willing and able to invest in it
4. The discipline to maintain consistency across many surfaces
Apple has all 4. I'm at a company that had 1-3 but really struggled with 4 pre-figma. The transition has allowed our design team to really focus their creative energies onto more impactful problems and much less time designing settings page #32. Admittedly this done mean the less talented designers have less fun when they're working, but this griping is exactly what I deal with from mid level engineers who want to work with latest shiny framework, just part of making good product IMO.
We already used this feature set today in a cross-team/cross-company collaboration and it was very helpful. We are doing design work for another firm that is doing the build and being able to communicate more easily what work is ready to move to what stage etc… improved our workflow, at least from the first glance. I am not sure how much long term efficiency there is to gain, but I suspect for us there will be a meaningful amount.
great. it has a VScode plugin, and exporting to CSS or swiftUI. that's all anyone will ever need. definitely worth fully buying into. im sure this will stand the test of time
237 comments
[ 548 ms ] story [ 3652 ms ] threadWe've also introduced an API extension point so third parties can now provide their own implementation of code snippers (code generation) in Figma's Dev Mode which Anima and a few other partners have already released plugins for :)
We developed an open source plugin that let you go from Figma to tailwindcss + react. Feel free to check it out
https://www.figma.com/community/plugin/1178847414663679049/B...
If there was some sort of asset export that obeyed some spec on how to size and file name that’d save hours and hours of work.
Outside of that, I’m probably not ever going to use generated code enough for it to be a game changer. Most of the time you’re having to fit some design into an existing design system, and so I don’t really see the use case for code export at scale.
But if you're using some icon library that a designer has imported into figma like remix-icon, just import from the library directly in code. Importing and rexporting the svg would likely change it slightly.
We use that and just paste it into the codebase.
I've also used a bulk export plugin that autonames things. Would have to lookup the plugin name if you're interested.
Often, the way the designer has grouped them together is not ideal for code, but I don't want to ungroup and group them all over again just so I can grab an SVG.
For instance, let's say you're a React developer. Designers set their layers as exportable in SVG, and Specify can automatically export the SVG string, optimize it with SVGO, set the end filename, and generate a JSX component for React - automatically. Here's a short video that should help you understand the whole process (https://youtu.be/Z7fX0v3KFmY?t=353).
You basically just have to configure Specify once, and every time designers update icons in Figma you'll get automated pull requests with icons transformed exactly how you want.
2024: separate license for Dev Mode
I guess Figma trying to get more paying customers
Edit: feel a bit Adobe vibe
If you're looking for something more custom, you can take advantage of our new Variables Plugin API beta (https://www.figma.com/plugin-docs/working-with-variables) and export them with what you need!
This is one of the reason we built Specify (specifyapp.com) which is a Design API that helps you sync design tokens and assets from Figma to any platforms and formats.
Specify helps you get automated pull requests containing your design tokens and assets defined in Figma.
You basically just have to configure Specify once, and every time designers update colors in Figma you'll get automated pull requests with colors transformed exactly how you want.
For a tool designed for visual collaboration it feels like a sizeable oversight that for me at least hinders workflow pushing me into other tools rather than keeping conversation contained alongside the files being discussed. Any plans in this area?
UK antitrust regulator is looking at the merger as well. (the same people that blocked activision microsoft deal in UK)
https://assets.publishing.service.gov.uk/media/64523aa4faf4a...
Here is an overview of all the features + screenshots: https://twitter.com/Chris_Smeder/status/1671565267145748480?...
1. Component playground
2. Redlining
3. Links to github in components
4. React mode
5. https://animaapp.com plugin will build the component for you...
6. Tasks from Jira and Linear in Figma
7. Figma in VS code
8. Autocomplete fill in code when you select a layer
FYI: To learn more about Dev mode, check out the live (free) workshop from Figma at 2pm PST https://config.figma.com/agenda?d=day-2
And here is the keynote where the announcement preview was shown https://youtube.com/watch?v=-44qrQDnLMM
What started this mentality?
My favorite was the PowerPoint presentation. Didn’t happen to me but I’ve heard about it.
1: Somewhat redundant. Any tiger you try to get teeth out is likely to be cranky before you finish the retrieval.
Yes, similar to the photoshop days. I forgot all about those. Has been almost 10yr since I had that happen!
PPT doesn't bother me because it's very "what we need" not "how we need it" so I don't have to worry about the specifics and instead can focus on (and ask questions about) the intent of the feature.
At least they didn't use document links with absolute paths. Macs don't have have a C:\Documents and Settings\Clueless\ folder. Encountered that a few times in my career.
for all that trouble it still beats getting `design.jpg`
I'd rather have a napkin sketch that we can work on together vs throwing pictures over the wall.
As impressive as it is, I feel like Figma makes this situation worse. It's like "see we've figured it all out devs, look how nice this looks. No discussion needed"
/s (at my previous company they did not ... lol!)
My favorite is when design adds data to a mock-up that we don't actually have. My company is, admittedly, a bit of a joke.
Also up there: design giving us mock-ups that are a composite of shit that needs done today and future shit they still haven't decided on. And then demand review approvals. No. You can't have it both ways you fucking morons. Either give me exactly what needs to be done, or you get no review rights. I'm not going to sit here for three weeks of back-and-forth while you play hunt-the-pixel and giving me hell for not matching the fog in your own head.
That's my favorite - if you mention responsive or how things should wrap or cascade you get the blank stares or "we aren't solving for mobile right now"
Don’t get me wrong, I have a ton of respect for good designers, but the best designers are those with a slight technical lean who are willing to design around e.g. built in customization on UIKit widgets instead of full wheel reinvention everywhere.
Yes, absolutely, and it's among the worst ways to develop software. Designers kept coming up with controls that required coding custom behavior not already provided by the toolkit, either by modifying and extending components or creating new ones from scratch. Designers blamed developers for causing "rework" when it was found that the design included things that didn't exist, and developers took the blame when it took longer to implement the mocks than designers had led project leadership to believe. The lead designer's solution was to more-or-less abandon the team's pretense of being agile and get everything completely frozen well in advance of any coding.
Also, the backend was horrific, as might be expected when leadership treated it as an afterthought. I got the impression that because the system was built to replace an existing front end, leadership believed that it was just matter of wiring the UI up to the services that already existed. Some very legacy services, think mainframe-era fronted by a thin SOAP-to-json layer. Yeah and some of the backend services that turned out to be required didn't even exist.
I'm glad I'm done with that consulting gig. It was not fun, it wasn't challenging, it was just a grind, and if it is complete and they are able to turn off the existing front end on schedule I'll be shocked, and I'd want to know what kind of dumpster fire they end up with.
The best designer I ever worked with did full HTML/CSS mockups but even those had to be rewritten into the development framework of choice.
To me Figma is a step up from the other ways I used to get designs.
Creating a design out of whole cloth and handing it over to a dev, with minimal interaction, seems lazy.
The problem isn't figma - it is how it is being used. I do think that figma is super super overkill, as if you pick a good design kit what's the point? Lots of wasted time.
I don't see the point of doing all the extra work, when in reality a wireframe works better in most cases (doesn't set you up for the "why doesn't it look like the figma" responses)
- "Text content does not match server-rendered HTML."
- "Hydration failed because the initial UI does not match what was rendered on the server."
- "There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering."
None of these should impact the videos, though, because the fallback (client-side rendering) should work too. So if that's causing the issue, it's because there's a larger problem enabling it.
You should see it in the From Community list or you can find it here:
https://www.figma.com/community/plugin/821138713091291738
Can't seem to edit my post.
Feedback welcome btw.
One thing I noticed after creating a simple button component was that it does not export the font family of the text within but that might be a Figma limitation.
Also I hope dev mode prevents designers from locking/hiding elements and layers, which makes it very difficult to export the elements you actually need.
True, when Sketch started switching to a subscription model, they've buried the link to renew the license very deep so it was really hard to find, but I guess they've came back to their senses and it is now available right on the pricing page.
[0]: https://www.sketch.com/pricing/
I find that there are few tasks in software development more uninteresting than converting Figma designs into React components. The day I no longer have to do that will be a great day indeed :)
Companies like Bifrost (YC W22) are working on this problem and already automatically generate React components from Figma autolayout designs.
I remember making very complex prototypes with choices represented as branching sequences of nearly identical frames, and thinking "if I could set a variable and just show or hide some layer based on that variable, my life would be so much easier", so I'm happy y'all added this. It must have been a ton of work to implement this by you and your team, so good on you for doing it.
https://www.figma.com/dev-mode/
I welcome many of the new features. It's great for designers who are more technically oriented, though enterable input fields would be nice.
I do wonder how non-technical designers are going to feel. The learning curve is definitely going higher.
I'm worried about the rather pricey per / seat cost. There are far more developers than engineers at most organizations, and this is really going to hurt the licensing cost. Definitely Adobe bean counters flexing its muscle.
how would this impact them? just use figma as usual i would assume
looking forward to giving this a spin, our design team tends to go the iterative artboard style with everything...so sussing out values can be a pain
Since designers share files, whether at the same time, or at later date, if you have someone on the team who is fully taking advantage of all the features, like the new variables, conditional logics, etc.., and you're not quite up to speed, you may not be able to do your job effectively or may mess up what others have done.
Understanding abstractions / reference / inheritance is a skill that developers take for granted. But for non-technical folks, it takes time. Many struggle for a very long time.
That doesn't sound like a bad deal to me. They're not taking away anything from free mode.
Fast-forward nine months, and Penpot has a boatload of new features as well as its own conference coming up in a few days. I tried it again recently, and it had come much further than I expected: not only have they implemented auto-layout (Figma's original killer feature, in my view), but with the added benefit of wrapping auto-layouts. They even announced a new roadmap item of grid auto-layout.
I loaded up a tutorial file and my enthusiasm was dampened a bit seeing how a complex document impacted performance – Penpot still has a long ways to go to match Figma there – but as a viable Figma competitor, I think Penpot might actually have a chance now. It's telling that even as Figma races ahead with this new release, there is one feature (auto-layout wrap) that Penpot got to first.
The funny thing would be if Penpot's rise, spurred by the threat of Adobe dominance, actually results in regulators giving Adobe the green light to complete its acquisition of Figma. Still, if this market becomes a healthy competition like Blender / Maya, everyone will win.
They had Wrap before Figma. They have Flex and Grid!
https://www.youtube.com/watch?v=VchMDD0PrZE
Send the ENG a SYN packet, and if they ACK They are an engineer... if they /dev/null your packet, its a DEV.
There's usually multiple developers/engineers for every designer on a team, so bringing them in to the product with features that require full privileges would certainly be a lucrative move for Figma.
Design systems, tokens, modules, over the top consistency/reuse, the programmatic approach to design is experienced by some as a major buzzkill.
She eventually came around, but these latest features may push her over the edge. I kind of feel bad. :-S
It would've been nice if they'd incorporated more design focused features:
> Improved and more intuitive drawing tool. Bezier experience in Figma is horrendous
> Keyframes
It's now way easier to both stop designers from adding one-off design and interaction patterns that confuse users and to write truly reusable components that allow us to iterate faster as a company while maintaining a high level of visual consistency and polish. That's a big challenge once you start hitting org sizes in the hundreds or thousands.
But I still empathize with those designers. It's mechanized design which to some feel like a prison for their creativity. Even more so when all designs start to look the same across companies, and then there's AI design still to come.
What you emphasize, speed/productivity, is indeed the credo of our world, but that doesn't necessarily align with the goal of design. Take Apple, they don't seem to care about speed or continuous delivery at all, yet are widely celebrated for design excellence.
Likewise, "consistency" does not mean you found the optimal design. Even Google admitted that Material Design was a poor choice for some of their (internal) products and couldn't make it fit.
For a large software product to be designed well I think you need at least the following four things organizationally:
1. Talented people
2. A collaborative culture that allow those people to argue their position
3. Leadership that believes in good design and is willing and able to invest in it
4. The discipline to maintain consistency across many surfaces
Apple has all 4. I'm at a company that had 1-3 but really struggled with 4 pre-figma. The transition has allowed our design team to really focus their creative energies onto more impactful problems and much less time designing settings page #32. Admittedly this done mean the less talented designers have less fun when they're working, but this griping is exactly what I deal with from mid level engineers who want to work with latest shiny framework, just part of making good product IMO.
Beginning of the end, and I say that as a previously huge Figma advocate.
Laying low on the cost charts would benefit you more than rinsing us and getting questioned “do we need that?”