As a developer, the "one big bulletin board" visual model that Figma promotes is one of the worst steps backwards in UX I have ever had to deal with. I am constantly zooming in and out and scrolling around trying to find anything. I hate it so much.
We use figma quite extensively as a reference for our current project. The disgners constantly move stuff around, so the links to them, in tasks, break and point to nothing. Which is a major pain in the ass indeed.
So yeah, 100% agree that the "big bulletin approach" is a negative.
I've completely reneged on linking to figma in individual tasks.
I take screenshots of the state of figma at the time we all agreed that "this is it" (or close enough to what we'll implement). Sure I'll leave a link in the epic to the figma "bulletin board" for that feature so that people can find it and look around. But that's it. We're also never gonna implement exactly what's shown in figma (or said screenshots) either because it would take forever to get the designers to actually adjust everything to look like it does in product.
They can never seem to get the look to match what our standard UI library looks like. Which is a shame because every new developer always tries to match what the design shows instead of sticking with the standard library. Honestly, the best thing would be if figma wasn't used at all and the designers just used black and white lines and boxes and focus on good UX instead of pixel perfect UI designs.
And this M.O. would seem to make zero steps toward recognizing the tedium of their platform:
"By hovering and clicking around the Figma canvas, you can find and export all the information you need"
Because "hovering" over every shape or area in a screenful of design content to prospect for hidden goodies, then exporting them one by one, is a great way for developers to acquire a complete rundown of what they need to implement.
I guess I can't speak for all developers, but I don't want to dick around with an Advent calendar that's masquerading as a design document.
Meanwhile, has Figma fixed the absurd confusion that it presents in the UI between projects and teams? It seriously confuses those two things right there on the "home" page of your account.
And finally, for those who don't want to support Adobe's software-rental nonsense, there is an open-source alternative to Figma called Penpot: https://penpot.app
My designers take their own snapshot by cloning their work and using versions in the names of things. Older things are not to be modified with few exceptions. It makes for a good linking experience on my end, but I don't know what that kind of maintenance is like for them.
Good product engineers just go with the flow - workflows with Figma is way up there, compared to without. Those folks were probably the early adopters, and they were much happier to work with designers now.
Minor design details tend to change and even if they are missed out, they get caught at some point - cost of dev rework is generally manageable.
Another big tool for bigger product teams has been component libraries (and corresponding Figma assets). That makes it all simpler.
I suspect, that the main problem is inconsistency in the underlying mental model, because there’s multiple individuals doing that and/or over longer periods of time.
I can typically figure out a mental model, even if designed by someone else (assuming they are somewhat consistent), pretty well and fast. — But it’s the inconsistency, that screws things up for me.
Ugh yeah when designers change things after a client signs off and in the middle of implementation. It confuses everyone and no one remembers what was actually signed off.
Name your frames and the problem is solved. I for instance love the model because I no longer have to be tracking down millions of filenames - just one for each project.
As a developer, I don't "name" anything on Figma. The UX designer might. I have to work with what I get. I agree with OP that in general it promotes placing a lot of components side by side on a huge surface and you have to keep zooming out and in, scrolling, etc.
It's a terrible experience.
I can for sure see how the 'big board' approach isn't good (and it looks like they're attending to this to some degree with the new Dev Mode features). I'm curious what handoff experience you had before that was better. Prior to Figma (as a designer) my workflows were always "send a PDF with designs, export some assets", which I imagine was non-standard, and not great, so I'm wondering what was improved for you before?
I had a brief and horrific period of my life when I had to export assets for android at the weird android resolutions.
I really don't understand why there isn't a better designer>developer hand off experience. It seems like Figma is trying with the CSS stuff and the layouts, but I don't think it quite works
Yup right. I find myself zoned out while zooming in and out frantically and achieving nothing. It's often difficult to effectively navigate without guidance from the creator of the board. Figma is better as a collab tool than a documentation tool.
As a MacOS user with a Logitech Ergo mouse, I haven't figured out how to navigate at all, and have to get my external trackpad out just to move around. If anyone knows how to move around Figma with a scroll wheel, please tell me, seriously. I would be glad to be wrong. That said, the touchpad experience is at least intuitive.
I'm a MacOS user at work and ThinkPad user in private and honestly, the MacBook (we have MacBook Pros) trackpad is awesome. I've never been so at ease with not having a mouse as I am with the work MacBook. It works with great precision for a regular mouse and zoom is awesome. It's also in exactly the right place, slightly off center and huge that I can use keyboard shortcuts and easily switch to mouse (i.e. trackpad) use when it's gonna be easier/faster to use the mouse to select/do something.
I'm never gonna buy into the Apple ecosystem on principle but product wise it's great to have it at work. On my ThinkPad I always go for my actual mouse when I need precision but the hand travel time between mouse and keyboard use is distracting.
I'm not sure if this is related to your gripe, but FYI, you can use the pinch to zoom gesture on the trackpad in Figma. I find that it works quite well.
I rarely use Figma but wanted to add that your experience isn't universal. I maintain one giant notes.txt file which I treat as my mental palace, finding sections within it by searching for "# keyword". This allows me to work as a 10x or 100x developer by avoiding bookkeeping chores like categorizing my notes, so more like a search engine. Figma might be targeted at designers who want to work fast also.
But I do agree that Figma needs an auto-organizing feature of some kind for people who receive the work. Perhaps with machine learning to track designs by the timestamp when they were edited, instead of their location on the page. Which could be as simple as a linear or hierarchical view which only scrolls along one axis, with tags similar to git/Sourcetree. Apologies if this already exists!
You might like Obsidian. It fits this mental model very well, and is all local.
I used to do exactly what you mention, and having a better interface now, but without lock in to a company has worked very well for me.
> This allows me to work as a 10x or 100x developer
What do you mean here? That this note taking method makes you 10 to 100 times better at your job?
I do something very similar except different files. But unstructured and rely on search to find things. Optimizes for writing. But this one trick makes you a 100x developer?
Hah, i'll be honest I thought you were kidding about the notes.txt - are you following some kind of standard? Or just spill everything into one big document?
The problem with these kind of pixel-perfect, inspectable design tools, is that there's no distinction between important details and unimportant details.
For example, if our app uses a letter-spacing of 1.2 for all the body text, and your Figma design uses a letter-spacing of 1.25, is that important? Or is that a mistake?
In something like Figma, being consistent is difficult for designers. But in code, being consistent is the default — exceptions are hard for developers!
There's a fundamental mismatch that just ends up being painful all around.
"The map is not the territory." Trying to get a design doc to 100% accuracy is often a waste of time. Design tools need a way to specify which details are important, and which are not.
In my experience the designer and the developer need to be co-located, either physically or virtually. There's just too many questions that come up during implementation of a design that can't be expressed in the design doc (or it's inefficient to do so) and so the feedback/communication loop between these two needs to be fast and high-fidelity. I.e., the dev can't be offshore while the designer is onshore. I've tried it a number of times and it never worked.
To be honest Figma gives plenty of tools to solve this problem. With various reusable components, font/color/sizing templates etc. Its reasonably easy to be extremely consistent with your measurements in figma, as long as designers spend the time to learn the tool, and not just use it like photoshop / illustrator.
Even resizability can be done quite well, allowing the designers to create reusable bits that stretch and squeeze to fit the needed space, and the way they deformed can be easily read (and verified!)
This is what a design system is about, you set up the standards of essentially an enum, give them names and say that if the designers want to change it or add something new, they need to add it to the design system. 14 point fonts becomes 'caption' size and so on.
When writing CSS for a Figma design, I first try to match the Figma as exactly as is reasonable, then I do a visual diff to make sure I haven’t missed any important details, then I clean up the CSS and relax some of the constraints until the (S)CSS is maintainable e.g. if I have padding of 19 and 21, lifting that out into a $padding: 20px constant.
Mockups are mockups, they’re suggestions. More often than not, sizes and spacing don’t match across views and it’s a waste of time to be “pixel perfect.”
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
> 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.
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!
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).
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!
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.
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.
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.
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
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.
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.
Hypothetically speaking, if all designers could code at the level of a Snr Front End Engineer, would Figma exist?
Just pretend that magically everybody knew how to code. Wouldn't designs just be done in the browser? No longer do you have to maintain these design artifacts post handover. There would be no unrealistic designs that do not consider the constraints of a browser window.
I know this is unrealistic but I often think about this.
I don't think so. While there are some scenarios that are better coded (where lots of different paths open up quickly, typically Excel-like), in many cases good designers are incredibly fast with Figma and I know no coder who can be that fast.
Also, they spend their time analyzing the problems and have many other things to hold in their head beside coding. It would be very challenging nowadays to both be a great UX designer and be current with the latest CSS evolutions.
That said, I wish more designers would try coding at some point and learn how a browser and website work to get a deeper understanding of the material they design for.
Also developers should understand the designers methods like journey maps, basic typography and layouting principles.
> It would be very challenging nowadays to both be a great UX designer and be current with the latest CSS evolutions.
Designers are supposed to be fluent in the medium they are designing for. Without understanding what's possible, what's easy, what's hard, what squeezes and what scales, or what's going to have a negative impact on site performance, how can one be a great designer?
It's very difficult to generalize but I'll chime in with my experience as both.
If I'm working on a backend system and have a (frontend) framework in place, I might easily skip Figma IF I have enough confidence that the approach/pattern/solution is the right one. If not, or if the particular UI is quite challenging, I would usually sketch things out in Figma until I can resolve the most important questions/design challenges. I would not bother making a high-fidelity design in this case.
If I'm working on a highly visual/presentational project, then Figma is my go-to, since code would be super slow and limiting if I want to explore various approaches and ideas. Especially I wanted to be a bit more creative with the presentation. However, I would probably design less than usually needed. Also, when coding this design, I would *not* consider my own Figma project to be a pixel-perfect representation of every single value in terms of font-sizes, spacings, etc. I would use a code-oriented system/approach and make sure everything comes close to the design. Certain details would be tweaked by eye in code as well if I feel they need visual adjustments. I suppose I also intuitively know which areas need more (pixel-perfect) attention and which are flexible.
And then there's exceptions and hybrids to all of these. I may want to polish a particular backend UI piece for whatever reason (Figma-first), or I might want to prototype/create a proof of concept for a complex state management, transitions, etc. (frontend-first) before making portions or all of it pixel perfect in Figma.
I am a software engineer and I still use Figma to be in design mode. Messing around with how a gradient/shadow looks or moving elements around is way quicker graphically than with code. It helps me not default to things that are easy to implement, but might be worse despite of it.
Still, I think your approach would work. I would probably find myself sketching on paper now and then in that situation though :)
As someone who has over the last 20 or so years been both a senior front end dev and a designer I don't think this is the case. For me designing in the the browser is fine for details but high level stuff; overall aesthetic, content design, user flow etc. etc. (the primary value of design per se) is better done, at least initially, with dedicated tools. Not necessarily because they're quicker (though they often are) but because different parts of my brain are needed for the different tasks and different tools fit better.
This change to Figma makes me less likely to choose it as my primary tool either as a designer or a developer. Though I guess this is a minority position as I'm compelled to use it all the time as Figma's become a kind of defacto standard in many sectors these days.
The iteration loop is MUCH faster using tools like Figma for design.
Most places use consistent patterns for padding, space, etc. But a lot of things need adjusted visually for polish. Tweaking things in devtools is fine for quick things, but can be lost on browser refresh.
Tools like "CSS Pro" make it easier. Saving devtools state makes it easier. But neither quite compare with hitting the arrow keys a few times to see what small adjustments look like. Or dragging a card to a different spot. Or duplicating a component three times with slight variations to see them side-by-side.
I'm a developer that uses Figma occasionally. It's just less frustrating to get the "look" down before jumping into code.
The frontend space is hilariously non-productive, while design really benefits from WYSIWG, or at least faster design-view iterations.
So unless some tools that were available decades ago with Visual Basic surfaces with drag’n’drop widgets, I doubt we can leave Figma and the like behind.
(Note: JavaFX does have a visual editor, not perfect but it was quite a great break from editing HTML files)
So yeah, 100% agree that the "big bulletin approach" is a negative.
I take screenshots of the state of figma at the time we all agreed that "this is it" (or close enough to what we'll implement). Sure I'll leave a link in the epic to the figma "bulletin board" for that feature so that people can find it and look around. But that's it. We're also never gonna implement exactly what's shown in figma (or said screenshots) either because it would take forever to get the designers to actually adjust everything to look like it does in product.
They can never seem to get the look to match what our standard UI library looks like. Which is a shame because every new developer always tries to match what the design shows instead of sticking with the standard library. Honestly, the best thing would be if figma wasn't used at all and the designers just used black and white lines and boxes and focus on good UX instead of pixel perfect UI designs.
"By hovering and clicking around the Figma canvas, you can find and export all the information you need"
Because "hovering" over every shape or area in a screenful of design content to prospect for hidden goodies, then exporting them one by one, is a great way for developers to acquire a complete rundown of what they need to implement.
I guess I can't speak for all developers, but I don't want to dick around with an Advent calendar that's masquerading as a design document.
Meanwhile, has Figma fixed the absurd confusion that it presents in the UI between projects and teams? It seriously confuses those two things right there on the "home" page of your account.
And finally, for those who don't want to support Adobe's software-rental nonsense, there is an open-source alternative to Figma called Penpot: https://penpot.app
Minor design details tend to change and even if they are missed out, they get caught at some point - cost of dev rework is generally manageable.
Another big tool for bigger product teams has been component libraries (and corresponding Figma assets). That makes it all simpler.
I can typically figure out a mental model, even if designed by someone else (assuming they are somewhat consistent), pretty well and fast. — But it’s the inconsistency, that screws things up for me.
I really don't understand why there isn't a better designer>developer hand off experience. It seems like Figma is trying with the CSS stuff and the layouts, but I don't think it quite works
My soul resonates with this
To be fair, they were all like that even before Figma, including Sketch.
But Figma doesn't allow you to link an artboard from one page to a one on different page, so it didn't allow designers to organize.
Don't get me started on lack of subfolders.
I'm never gonna buy into the Apple ecosystem on principle but product wise it's great to have it at work. On my ThinkPad I always go for my actual mouse when I need precision but the hand travel time between mouse and keyboard use is distracting.
But I do agree that Figma needs an auto-organizing feature of some kind for people who receive the work. Perhaps with machine learning to track designs by the timestamp when they were edited, instead of their location on the page. Which could be as simple as a linear or hierarchical view which only scrolls along one axis, with tags similar to git/Sourcetree. Apologies if this already exists!
What do you mean here? That this note taking method makes you 10 to 100 times better at your job?
I do something very similar except different files. But unstructured and rely on search to find things. Optimizes for writing. But this one trick makes you a 100x developer?
Makes it way easier.
For example, if our app uses a letter-spacing of 1.2 for all the body text, and your Figma design uses a letter-spacing of 1.25, is that important? Or is that a mistake?
In something like Figma, being consistent is difficult for designers. But in code, being consistent is the default — exceptions are hard for developers!
There's a fundamental mismatch that just ends up being painful all around.
"The map is not the territory." Trying to get a design doc to 100% accuracy is often a waste of time. Design tools need a way to specify which details are important, and which are not.
Even resizability can be done quite well, allowing the designers to create reusable bits that stretch and squeeze to fit the needed space, and the way they deformed can be easily read (and verified!)
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.
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.
Deleted Comment
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.
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.
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.
Dead Comment
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.
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.
Design systems, tokens, modules, over the top consistency/reuse, the programmatic approach to design is experienced by some as a major buzzkill.
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.
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
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.
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?”
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.
Send the ENG a SYN packet, and if they ACK They are an engineer... if they /dev/null your packet, its a DEV.
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?
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.
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.
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
Just pretend that magically everybody knew how to code. Wouldn't designs just be done in the browser? No longer do you have to maintain these design artifacts post handover. There would be no unrealistic designs that do not consider the constraints of a browser window.
I know this is unrealistic but I often think about this.
Also, they spend their time analyzing the problems and have many other things to hold in their head beside coding. It would be very challenging nowadays to both be a great UX designer and be current with the latest CSS evolutions.
That said, I wish more designers would try coding at some point and learn how a browser and website work to get a deeper understanding of the material they design for.
Also developers should understand the designers methods like journey maps, basic typography and layouting principles.
Designers are supposed to be fluent in the medium they are designing for. Without understanding what's possible, what's easy, what's hard, what squeezes and what scales, or what's going to have a negative impact on site performance, how can one be a great designer?
If I'm working on a backend system and have a (frontend) framework in place, I might easily skip Figma IF I have enough confidence that the approach/pattern/solution is the right one. If not, or if the particular UI is quite challenging, I would usually sketch things out in Figma until I can resolve the most important questions/design challenges. I would not bother making a high-fidelity design in this case.
If I'm working on a highly visual/presentational project, then Figma is my go-to, since code would be super slow and limiting if I want to explore various approaches and ideas. Especially I wanted to be a bit more creative with the presentation. However, I would probably design less than usually needed. Also, when coding this design, I would *not* consider my own Figma project to be a pixel-perfect representation of every single value in terms of font-sizes, spacings, etc. I would use a code-oriented system/approach and make sure everything comes close to the design. Certain details would be tweaked by eye in code as well if I feel they need visual adjustments. I suppose I also intuitively know which areas need more (pixel-perfect) attention and which are flexible.
And then there's exceptions and hybrids to all of these. I may want to polish a particular backend UI piece for whatever reason (Figma-first), or I might want to prototype/create a proof of concept for a complex state management, transitions, etc. (frontend-first) before making portions or all of it pixel perfect in Figma.
Still, I think your approach would work. I would probably find myself sketching on paper now and then in that situation though :)
This change to Figma makes me less likely to choose it as my primary tool either as a designer or a developer. Though I guess this is a minority position as I'm compelled to use it all the time as Figma's become a kind of defacto standard in many sectors these days.
Most places use consistent patterns for padding, space, etc. But a lot of things need adjusted visually for polish. Tweaking things in devtools is fine for quick things, but can be lost on browser refresh.
Tools like "CSS Pro" make it easier. Saving devtools state makes it easier. But neither quite compare with hitting the arrow keys a few times to see what small adjustments look like. Or dragging a card to a different spot. Or duplicating a component three times with slight variations to see them side-by-side.
I'm a developer that uses Figma occasionally. It's just less frustrating to get the "look" down before jumping into code.
So unless some tools that were available decades ago with Visual Basic surfaces with drag’n’drop widgets, I doubt we can leave Figma and the like behind.
(Note: JavaFX does have a visual editor, not perfect but it was quite a great break from editing HTML files)