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.
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.
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?
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.
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!
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.
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.
> 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.
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.
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 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'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)
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.
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"
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.
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.
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.
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.
Since figma devs are looking at this thread, could you please add proper p3 color space support? Everyone’s phone supports p3 at this point, especially iphones and the gap prevents mobile designs from looking the best they can be because there is too much friction to use it. Sketch supports it!
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.
A designer using Figma is equivalent to a developer using no code solutions. The design is compromised and potential to do something great is capped. I prefer an illustrator art board over Fisher Price my first UI apps. Wire-framing UX is best done with the freedom of a large art board to play in. Extra points if you design UI completely with vector. God mode if you build your own components.
Do you have an example of something you can’t do in Figma that you’d like to do for web design?
This is a strong statement, and I get the sense that you haven’t used the tool much, but I’m curious on your take here. For context, I’m the PM who owns component creation in Figma.
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
For me, as an Android developer, this is a huge improvement.
Finally, I can easily select elements that were non-selectable-without-holding-cmd in the "design" mode. The thing that shows paddings and margins is a godsend, AND it stays put when you move your mouse somewhere else and switch to another window. The size tooltip also now shows the actual helpful size in pixels in addition to the unhelpful "hug/fill".
The choice of Jetpack Compose as the only Android code format is strange. Most people, even those who do embrace The Google Way™ of Android development and Kotlin itself, don't take it too seriously and don't consider it production-ready. It would be nice to have support for the good old XML layouts.
Interesting, I'm not an Android developer myself but at least our Android teams seem to really really like Compose. In fact yesterday I overheard one of the guys say, "Almost everyone in the industry is switching to Compose these days". (Not sure that's true but still.)
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 :)
The VS Code extension looks cool but I don't understand Dev Mode. Are you saying you could not click on elements in Figma to see the properties before? How do you edit things?
Considering my question I'm obviously not a Figma user so maybe I've misunderstood it.
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.
I understand that this is attractive for Figma because it broadens their market and allows them to sell developer-specific plans, but honestly, what I need is not so much tools for myself, but for Figma to nudge my designers to make things more easily consumable by engineers. So that means nudging them to specifying a colour and font palette once and defaulting to using and re-using those, with straying from them being an exception. It means getting them to specify how different elements should flow, rather than them all being absolutely positioned at some particular X and Y coordinates. And just in general have them draw the design with tools that work more closely to the way CSS works.
I believe penpot.app is supposed to work like this, but unfortunately I haven't been able to try that yet.
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!
I see you can start linking things to urls/files, curious as to if this will unlock developers adding more metadata to designs which might eventually be nicely displayed in Figma.
I have a desire to try Figma out as a project management tool, as in being able to easily visualize which screens/flows have been implemented by a developer, which ones have been updated since. I believe Figma is a good tool for that as it is visual and often already used to show things to clients.
Framer [1] seems mind-blowing for small product teams. Or at least the idea of it if Framer can be adopted successfully by a small team. I tried it briefly on a small project, it felt powerful, but big disclaimer we never went to "prod" on that project. Also I am not sure about performance, etc. Any thoughts or anecdotes?
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.
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.
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?...
Having autolayout items wrap is huge for my use case, and having min/max dimensions is a really useful addition too. Both features feel like steps on the way to having prototypes with responsive breakpoints, which is a long-requested feature too.
This is an outright Zeplin killer. This does make Figma even more enterprise and team first rather than simpler design tools. I would love to see an emergent design tool alternative really which is simpler in its philosophy.
Now I need to switch between design and dev mode to get all the information I need. Typography style name is accessible in Design mode only, and margins are visible in dev mode only
Taking away the INSPECT tab and then charging me $25 per seat to use its replacement is insane to me. I love the integrated feel of having these things in Figma, but these paywall barriers are becoming a big adoption issue for my design and eng team.
Last year we all kind of switched to Figjam from Miro and it's been a good transition — and the Net Dollar Retention of Figma is insanely high at 200%+. So they probably want to keep that going... but this just seems like too hard a squeeze.
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
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?
bgribble|2 years ago
Akronymus|2 years ago
So yeah, 100% agree that the "big bulletin approach" is a negative.
dangom|2 years ago
drewbeck|2 years ago
paulddraper|2 years ago
My soul resonates with this
esjeon|2 years ago
pcurve|2 years ago
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.
revskill|2 years ago
zackmorris|2 years ago
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!
pbarnes_1|2 years ago
SkyPuncher|2 years ago
Makes it way easier.
nateroling|2 years ago
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.
maroonblazer|2 years ago
seer|2 years ago
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!)
novok|2 years ago
sethgoodluck|2 years ago
zarzavat|2 years ago
mrxd|2 years ago
ryanSrich|2 years ago
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.
uxamanda|2 years ago
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.
pelagic_sky|2 years ago
JusticeJuice|2 years ago
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.
chuckn0risk|2 years ago
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.
kijin|2 years ago
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.
pininja|2 years ago
wetpaws|2 years ago
[deleted]
pcurve|2 years ago
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.
forkbomb123|2 years ago
dahwolf|2 years ago
Design systems, tokens, modules, over the top consistency/reuse, the programmatic approach to design is experienced by some as a major buzzkill.
jozzy-james|2 years ago
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
whywhywhywhy|2 years ago
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?”
dsgnr|2 years ago
jononomo|2 years ago
riedel|2 years ago
whywhywhywhy|2 years ago
emilsjolander|2 years ago
cbovis|2 years ago
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?
Domenic_S|2 years ago
zyang|2 years ago
ypeterholmes|2 years ago
megaman821|2 years ago
welder|2 years ago
yewenjie|2 years ago
sebazzz|2 years ago
beanaroo|2 years ago
raphaelschaad|2 years ago
robertoandred|2 years ago
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.
KnobbleMcKnees|2 years ago
shlubbert|2 years ago
csmeder|2 years ago
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
jsncbt|2 years ago
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.
maigret|2 years ago
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.
jastuk|2 years ago
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.
mejutoco|2 years ago
Still, I think your approach would work. I would probably find myself sketching on paper now and then in that situation though :)
tomgp|2 years ago
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.
coxley|2 years ago
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.
kaba0|2 years ago
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)
roflyear|2 years ago
What started this mentality?
cratermoon|2 years ago
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.
gedy|2 years ago
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"
jmuguy|2 years ago
kayodelycaon|2 years ago
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.
obeid|2 years ago
devmor|2 years ago
CSMastermind|2 years ago
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.
novok|2 years ago
aabhay|2 years ago
1023bytes|2 years ago
Vorh|2 years ago
- "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.
emilsjolander|2 years ago
spacebacon|2 years ago
jjcm|2 years ago
This is a strong statement, and I get the sense that you haven’t used the tool much, but I’m curious on your take here. For context, I’m the PM who owns component creation in Figma.
wdb|2 years ago
pcurve|2 years ago
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...
pininja|2 years ago
seanwilson|2 years ago
https://www.figma.com/dev-mode/
grishka|2 years ago
Finally, I can easily select elements that were non-selectable-without-holding-cmd in the "design" mode. The thing that shows paddings and margins is a godsend, AND it stays put when you move your mouse somewhere else and switch to another window. The size tooltip also now shows the actual helpful size in pixels in addition to the unhelpful "hug/fill".
The choice of Jetpack Compose as the only Android code format is strange. Most people, even those who do embrace The Google Way™ of Android development and Kotlin itself, don't take it too seriously and don't consider it production-ready. It would be nice to have support for the good old XML layouts.
codethief|2 years ago
yewenjie|2 years ago
emilsjolander|2 years ago
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 :)
replygirl|2 years ago
Kiro|2 years ago
Considering my question I'm obviously not a Figma user so maybe I've misunderstood it.
zui|2 years ago
2024: separate license for Dev Mode
I guess Figma trying to get more paying customers
Edit: feel a bit Adobe vibe
taylorlapeyre|2 years ago
metalrain|2 years ago
There is still disconnect how to interpt the layout from lower level back to structural abstractions.
Like margin of 24px may actually be 16px default margin + 8px additional margin for this element type.
I'm not sure if Figma or other design tools can solve this disconnect, but I think that would help a lot.
Vinnl|2 years ago
I believe penpot.app is supposed to work like this, but unfortunately I haven't been able to try that yet.
pininja|2 years ago
_betty_|2 years ago
I have a desire to try Figma out as a project management tool, as in being able to easily visualize which screens/flows have been implemented by a developer, which ones have been updated since. I believe Figma is a good tool for that as it is visual and often already used to show things to clients.
balaji1|2 years ago
[1] https://www.framer.com/
karaterobot|2 years ago
jjcm|2 years ago
throwaway20222|2 years ago
arecurrence|2 years ago
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 :)
nopeYouAreWrong|2 years ago
karaterobot|2 years ago
mercurialsolo|2 years ago
kubenqpl|2 years ago
unknown|2 years ago
[deleted]
pineapple_sauce|2 years ago
obeid|2 years ago
spandrew|2 years ago
Last year we all kind of switched to Figjam from Miro and it's been a good transition — and the Net Dollar Retention of Figma is insanely high at 200%+. So they probably want to keep that going... but this just seems like too hard a squeeze.
pirsquare|2 years ago
jhatemyjob|2 years ago
jhatemyjob|2 years ago
parentheses|2 years ago
cratermoon|2 years ago
view|2 years ago
theultdev|2 years ago
You should see it in the From Community list or you can find it here:
https://www.figma.com/community/plugin/821138713091291738
emilsjolander|2 years ago
rco8786|2 years ago
shaan7|2 years ago
logicchains|2 years ago
joanne123|2 years ago
[deleted]
nocontextpls|2 years ago
[deleted]