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.
At a previous job me and my team (UX Design) were so well meshed with the developers that I could hand them a text outline of the page structure I wanted of our design system components and they could produce it with 90% accuracy. Afterwards I would sit with them at their desk and we’d work out the last 10% together - either things I hadn’t thought of or bits they weren’t sure how to implement. It was glorious and it’s still the highlight of my professional life.
Unfortunately that’s been the exception in my personal experience, so most of the time I have to produce pixel-perfect comps that leave nothing to the imagination.
This is the ideal workflow that I would like to strive towards.
Unfortunately, the product designers don't seem to want to let go of Figma. I understand that this helps them think and organise the layout so perhaps it's not really a problem.
Figma and Sketch are fine and necessary for design tasks. We still need to quickly conceptualize and iterate on design ideas, including creating comps for research purposes.
The missing link, often, is then formalizing the design in some form that both developers and designers can use.
At the job I mentioned in my anecdote, we had a guy who lead our design system team. He had string design experience and was also a front end developer. He acted as the interface between the dec Org and the design team to create and develop a component library that was actually used in production and documented on an internal site.
Devs had real code they could use and design could focus on future products and reducing existing things.
"I have a design I would like produced. Please make it like this please."
I couldn't imagine giving a machinist or welder a drawing containing no annotations. (This would be something an intern does once and the shop calls them up to tell ask them questions about what they actually need for 45min. Probably sending them back to rework it)
Pulling from the mechanical world:
* make 3d models (equivalent to HTML/CSS components)
* put 3d models into an assembly (HTML components together on the page)
* make variations of the assembly to show range of motion (variations on user activity)
* make "drawings" that contain components that are broken down to the smallest practical level (this would map to: modal, tables)
** in software these are usually managed similarly to Spreadsheet tabs
** this would contain a reference to the 3d parts + dimensional annotations. This means updating the assembly/part geometry automatically updates the drawing
* anytime significant changes are made, issue new "Revisions" of those "drawings" are committed, issued, and then sent to the shop
* 3d modeling software has change management systems so you'll automatically know if your proposed changes to a 3d part will break a drawing or assembly that depends on it
For us, figma has the final say in looks. So, it's actually a benefit that the designers can change it afterwards, as it is refined. They still have no incentives to keep the links up to date, though.
Being able to change things as design is still in flow is great, agreed. Once something is agreed upon the ability to change things without notice is really bad, especially if you're expected to follow the design as it has "final say". You go an implement something on Monday based on designs and show it to stakeholders on Tuesday. They compare with the figma board and flogg you because it looks nothing like it. Ugh! (yes that's also a process failure but absent better processes I make my own process that doesn't get me flogged ;) )
That sounds like an opportunity to improve on collaboration (i.e. people talking, notifying each other) as well as trust ("compare with the figma board and flogg you because it looks nothing like it")
For instance, if something is agreed upon and a designer changes it afterwards, they could simply give you a heads up that they intend to do so with context so the two of you can discuss.
They could. They don't. It may not even be their fault. They don't know. They just change things. They live in their world. You tell them, they are sympathetic, apologize, vow to do better next time. They're in their world. They do it again.
The flogging still happens. Is that broken? Yes! Does it still happen in too many companies? Yes! Is there an easy fix where you "trust but verify"? Yes! (as in, sure I trust they will notify me next time, which even if they actually do may be too late. So we made the process "figma is the 'working theory' and what we actually build will sorta look like that". Not every stakeholder may understand that but we sure will tell them when the flogging is about to start. (I say flogging, but in reality it's a gradient of course and while in some companies it will resemble an actual flogging quite closely in others it's more like what you describe. Not all countries and companies are as chill as some others ;))
> They could. They don't. It may not even be their fault. They don't know. They just change things. They live in their world. You tell them, they are sympathetic, apologize, vow to do better next time. They're in their world. They do it again.
We can use your language and persuasive skills to effect change. That change might be better collaboration. That change might be the person gets fired because it, together with other behavioral patterns, are judged to yield poor outcomes. Outcomes that are not good enough.
That's why I really like working in true cross-functional teams. A Product Manager, a Product Designer and a handful of engineers. Do standups and all ceremonies together.
Ideally this "product team" is also empowered to solve a problem instead of tasked to build a feature.
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.
This is my method, especially because it shows how design will progress, with tight deadlines this becomes harder but I still consider it a very valuable way of proving work (only a minor designer though with freelancing)
I certainly can understand stand the move fast method of quickly changing things, when I'm doing concept work this makes more sense here.
Long term though, if you actually care about your work you should be making copies or different boards to show how and when you made some decisions. Especially mayor design changes.(Granted I could just be a bad designer that just can't come up with a better workflow)
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.
This is good, yes, but it requires that the team culture does not treat minor deviation from the Figma document as a bug or a failure of the developer. That mindset isn't always present, and it's not usually up to the product engineers themselves. It requires buy-in from the designers, product people, and managers.
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.
In my last job designers would put “in progress” in the title. But occasionally would make minor updates on final designs that would need to be communicated.
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
In figma you set the export options for different layers (say png of x resolution, and svg), and you can export them all at once. Unless I am missing something, this should solve your problem.
Thankfully in year 2023 it’s not a problem anymore since everything can be vector.
I’m talking about 2015-16 when you had to use raster images for components and figma was not even a thing.
But thank you nonetheless.
My current complaint about figma is that even if I take time to set up all the dynamic scaling and layouts I don’t think it as useful for devs as I hoped it would be in my mind. (As in I thought u can just copypaste the code snippet). But i’m not quite sure as I have not done much IC design work in years aside some odd jobs for friends and perhaps they are just shit programmers or I am not using it right.
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?
Maybe not 10x but even just noting stuff means that picking up an older task that you had to shelve before could go from a 15 minute thing to a 30 second thing depending on what context you put down/how accessible it is.
Ultimately a lot of this stuff is commingled with comfort with tools and general ability to juggle things though, so hard to isolate the effects
Ya sorry, poor wording on my part. What I meant was, if I use every trick in my arsenal, I can effectively go around a problem entirely and maybe reach 100x faster than when I was a fresh grad writing my own data structures by hand. Lately I've been dragging so badly though that I'm probably at 10% or even 1% productivity, negating my experience and putting me on par with my original inexperienced self, albeit with reduced effort.
Edit: my actual point was that if a person works along their natural tendencies, they'll probably be faster than if they have to fight their instincts (and take time to organize in this case), mainly because they might fall out of the zone
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?
I do something similar and just dump everything into a giant chaotic document. It works well because I intuitively understand my own personal brand of chaos, so I know how to easily find everything.
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.”
As I said, I don’t try to make the end result pixel perfect. I try to cut a balance between being faithful to the design and having maintainable code.
Spacing and sizes do matter though. There’s a reason why we have thousands of different fonts, even though 5 would be sufficient. When lengths are proportionate it creates positive feelings in the user. People are unconsciously very perceptive to small changes in proportions - it’s sexual attraction.
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.
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.
"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.
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.
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.
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?
Designers should be very familiar with the standard widgets, idioms, and interactions of the platforms they're designing for, but I don't think performance is rightfully something they should have to worry about.
> but I don't think performance is rightfully something they should have to worry about
But then I, as a developer, have to argue with the designer why a table containing a thousand rows or more, with no pagination, may not be a good idea :-(
I think a good designer polls his dev team to help him figure out what’s a “big lift” and whats easy. And a good developer works with her designer to point out “big lifts” and helps find compromises!
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"
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.
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.
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.
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.
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, 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.
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`
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.
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)
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.
Figma is “web design” exclusive. Putting yourself in the web design bucket trades creativity for utility. Design snobs that have pushed the envelope for decades (26 years for me) depend on not being in a preconceived bucket to redefine what web design actually is. Figma is great for rapid prototyping but rapid is not a priority when reinventing the web. Most big leaps in design are born from the tension of designer and medium. For example, a designer and the printing press or in our case here the healthy tension between a designer and a developer.
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.)
I'm personally on the opposite end of this spectrum. My projects don't use neither Kotlin nor even AppCompat. The AndroidX libraries that I need (because Google can't be assed to ship them as part of the system) like RecyclerView I use as my own fork that doesn't depend on anything else. I wholeheartedly despise what Google does to the Android development ecosystem. Google is not a good steward of Android.
Other developers I know approach Compose with caution and mostly use it for experiments, not in their real apps.
I'm commenting here to agree, and because what you say is so specifically similar to my outbursts a good number of my colleagues would mistakenly believe I am you from this comment, and they regularly accuse me of being the only one!
It would be incredibly hard to do a worse job of shepherding the Android platform than Google have managed to do. It's no surprise iOS is growing.
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.
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 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.
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.
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?...
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.
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?
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.
