[dead]
Making Figma better for developers with Dev Mode
141–150 of 238 posts
Re: Making Figma better for developers with Dev Mode
#142For 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…
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.)
Re: Making Figma better for developers with Dev Mode
#143As 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.
Re: Making Figma better for developers with Dev Mode
#144Earlier quoted context omitted.
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) e…
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.
Re: Making Figma better for developers with Dev Mode
#145As 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.
As a MacOS user, zooming on a touchpad is painful.
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.
Re: Making Figma better for developers with Dev Mode
#146As 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.
Looks like the new feature should help...
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.
Re: Making Figma better for developers with Dev Mode
#147Earlier quoted context omitted.
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) e…
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 ;) )
Re: Making Figma better for developers with Dev Mode
#148As 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.
As a MacOS user, zooming on a touchpad is painful.
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.
Re: Making Figma better for developers with Dev Mode
#149As 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 feel like this is the UX designers version of “gives you enough rope to hang yourself with.”
Re: Making Figma better for developers with Dev Mode
#150Earlier quoted context omitted.
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.
Wait, your product people talk to devs? /s (at my previous company they did not ... lol!)
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.