Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Figma starts designing us

designsystems.international

Post reply on HN
Print view View original

81–90 of 145 posts

Re: When Figma starts designing us

#81

Post by no_wizard »

wx196 wrote: post #26
_bent wrote: post #13

Earlier quoted context omitted.

It doesn't play to the strengths of designers to have them think in terms of Flex layouts and it doesn't play to the strengths of developers to have them translate a design 100% specified to the layout-algorithm and hierarchy of components into code. Yet this is the workflow Figma encourages. What the author encourages is that the designers work more free-flowing with sketches and wireframes and that the developers t…

Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-...

now to get designers to actually use these things.

Figma has a bunch of good tooling, but getting designers to use it, and use it consistently, is the real problem.

Designers exist in a realm seemingly, where outside pressure can't really be put on it from an organizational level to get them to uniformly adopt a set of standards they will always adhere to. Every company I have worked at, big, medium, small, seems to have this problem

Re: When Figma starts designing us

#82

Post by no_wizard »

Lalabadie wrote: post #55
zdragnar wrote: post #45

Earlier quoted context omitted.

Unless you're building content-marketing or similar- you don't need a lot of the exploratory phase to be done freeform. Trying to implement designs in a product where every single new design stretches or modifies the design system is mind bogglingly annoying as a developer, especially if you've got a small team trying to crank out new features. We don't need a tenth variation of a call to action, we don't need to use…

These are complaints about the designer you are working with and the deliverables they're choosing to give you, are they not? Figma isn't/shouldn't be the arbiter of what's possible in the project, that's a major point of the article. My role as a designer is to explore options and _then_ narrow down to a sensible solution (diamond-shaped process, etc etc). My developer colleague is concerned by the second part of th…

>These are complaints about the designer you are working with and the deliverables they're choosing to give you, are they not?

It is, to some degree, but the tools don't help any related party enforce consistency that will translate to the broader output of that work, that doesn't help matters very much.

In addition, designers themselves by and large don't seem to care enough about consistency like this. Engineers have design systems (ideally) that they pull from, but I'm still shocked in 2025 there is no good 1-1 communication of imposing the constraints of a design system in the designer engineer workflow.

Not to mention, for every designer I know that does adopt features of the tool that make this easier, like auto layout, there's a much greater number of designers that refuse to use them.

Seemingly, engineers hold themselves to a higher standard of consistency than designers do. I've seen this pattern too many times and its the only reasonable conclusion I've been able to draw. I was even hired to help streamline engineering and design work together and share as much as possible to get a corporate design system adopted, and I always had a hell of alot more resistance and argument with the design side of that equation on this.

edit: after seeing someone from Figma comment, I feel its unlikely it will ever have any of these types of features, which is a shame

Re: When Figma starts designing us

#83

Post by danielvaughn »

ThePatientTiger wrote: post #74
danielvaughn wrote: post #33

Earlier quoted context omitted.

I’m actively working on an alternative right now. It’s a tool for designing in the browser, using HTML and CSS. Everything is parametric by design, including tokens. Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.

That would be awesome, Looking forward to it.

Thanks, I can’t wait to showcase it on here. It’s frustrating because I can only work on it on nights and weekends, and my 15 month old daughter doesn’t make that any easier.

I’m incredibly pumped for it, though. It’s almost entirely keyboard driven, kinda like Vim. I’m building this rich set of mnemonic commands to build/design UI components. It’s like Vim + Storybook + WebFlow.

Re: When Figma starts designing us

#84

Post by SirHumphrey »

marcosdumay wrote: post #61
screye wrote: post #36

Earlier quoted context omitted.

Isn't this the problem with all no-code / low-code platforms ? Code is merely the leanest human-readable representation for loss-less specification of requirements. We're seeing this same pattern with 'K8s YAMLs' and 'prompt engineering'. There is an entire industry that's re-inventing new DSLs which inevitably converge to a scripting language as requirements get more complex. Instead of reinventing the abstraction,…

> Code is merely the leanest human-readable representation for loss-less specification of requirements. Hum... That's assuming you have a perfect development stack that hides all non-essential complexity. And well, I have news for you, that's a low-code platform. A generic stack that hides every problem but solves every requirement just can't exist.

While code may no be the leanest human-readable representation, scripting languages are a quite deep local minimum. There is a difference between hiding complexity and blocking you off from complexity. Scripting languages work because when you encounter a problem your library / framework can't fix, there is at least a basic procedural Turing complete language to fall back on.

Re: When Figma starts designing us

#85

Post by no_wizard »

jjcm wrote: post #50

PM on Design Systems here at Figma. There's an element of truth to this post, but I think the author's conclusions are incorrect. First is the truth - we are working on things that allow designs to be closer to code (allow here is the key word, not enforce). We've always seen Figma as being at the center between Freeform and Structured design - I talked about it in depth during our keynote at Schema 3 years ago: http…

>allow here is the key word, not enforce

Is there any way you can get a global toggle to change that? Because enforce is what is often desired but its not possible to put sufficient guard rails in place to do so. Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one

>The most important thing though is you can always detach from them. One of the top requests we've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.

Its not always useful to be able to let people do this though, if you're implementing a feature in applications design side, and it needs to best represent the constraints of the team who will need to implement it on the engineering side, shared constraints would be amazing so they don't diverge too much, and you can get actual consistency.

What you're basically saying is: fuck consistency, this tool doesn't care about an organizations need to enforce that on a tool level

Re: When Figma starts designing us

#86

Post by miiiiiike »

NewsaHackO wrote: post #37
miiiiiike wrote: post #10

No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…

Are you saying thread product is laggy or your development process? If it's the latter, you sure youdont just need to update your computer?

No. It's just not implemented in a way that would let it support a large design system, even on a 16-core machine with 128GB of RAM.

Re: When Figma starts designing us

#87

Post by martinald »

jjcm wrote: post #50

PM on Design Systems here at Figma. There's an element of truth to this post, but I think the author's conclusions are incorrect. First is the truth - we are working on things that allow designs to be closer to code (allow here is the key word, not enforce). We've always seen Figma as being at the center between Freeform and Structured design - I talked about it in depth during our keynote at Schema 3 years ago: http…

FWIW I think you're mostly on the right track. I have noticed the "implementation ability" of designs that have came over from designers since figma had autolayout massively improve.

Maybe there is an argument that it is stifling creativity (though I'm not entirely convinced of this), but it is saving SO MUCH eng time on implementing (or going back and forth) on 'non standard' elements that are often not very intentional nor have the designers realised the impact of them, especially when it comes to responsive design.

FWIW I think the next big improvement (from eng side) would be some sort of (simplified?) git style version control for figma. For big projects with many people collaborating this would be hugely helpful, but would actually be hugely useful even with small teams.

We often spend so much time as engs implementing designs to find out they were one revision behind or hadn't actually been signed off, especially working remotely.

Re: When Figma starts designing us

#88

Post by Oarch »

mananaysiempre wrote: post #3

So, I’m not familliar with whatever Figma’s Auto Layout is, but the complaint still feels somewhat wrongheaded. Design ≠ print design; if you’re designing for a reflowable medium, you’ll have to design to its constraints. A good prototyping tool should allow you to go outside the constraints for the moment, but for a web or mobile designer to dismiss those constraints as the engineer’s concern is about as appropriate…

It's absolutely trivial to make any element ignore the auto-layout grid.

Re: When Figma starts designing us

#89

Post by jjcm »

martinald wrote: post #87
jjcm wrote: post #50

PM on Design Systems here at Figma. There's an element of truth to this post, but I think the author's conclusions are incorrect. First is the truth - we are working on things that allow designs to be closer to code (allow here is the key word, not enforce). We've always seen Figma as being at the center between Freeform and Structured design - I talked about it in depth during our keynote at Schema 3 years ago: http…

FWIW I think you're mostly on the right track. I have noticed the "implementation ability" of designs that have came over from designers since figma had autolayout massively improve. Maybe there is an argument that it is stifling creativity (though I'm not entirely convinced of this), but it is saving SO MUCH eng time on implementing (or going back and forth) on 'non standard' elements that are often not very intenti…

> I think the next big improvement (from eng side) would be some sort of (simplified?) git style version control for figma

FWIW, we do have a simplified version of version control already - there's both version history as well as branching & merging in Figma. There are some restrictions with it however that make it less compatible with the way engineers think about versioning - namely you can't tie it to a version number, and you can't have multiple versions in use at once (ie you can't publish both a 2.0 and a 3.0 version of a library). We are looking at improving this, but as I think you caught on, there's a balance between making it equivalent to eng flows while also simple enough for more casual designers.

Re: When Figma starts designing us

#90

Post by jjcm »

no_wizard wrote: post #85
jjcm wrote: post #50

PM on Design Systems here at Figma. There's an element of truth to this post, but I think the author's conclusions are incorrect. First is the truth - we are working on things that allow designs to be closer to code (allow here is the key word, not enforce). We've always seen Figma as being at the center between Freeform and Structured design - I talked about it in depth during our keynote at Schema 3 years ago: http…

>allow here is the key word, not enforce Is there any way you can get a global toggle to change that? Because enforce is what is often desired but its not possible to put sufficient guard rails in place to do so. Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one >The most important thing though is you can always detach from them. One of the top requests we…

> Is there any way you can get a global toggle to change that? Because enforce is what is often desired

I agree with your premise, but not with your conclusion. A way to block detaches would not bring this closer to code - there's no real concept of "detach" in code, but you can always simply create a new component. In the same way, we want designers to have the capability as well. You do land on the correct way to address this however:

> Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one

Linting on handoff, aka process, is the way to solve this, not dogmatic restrictions. You should always provide freeform design, otherwise your design language never evolves to changing requirements, but doing so should be an explicit choice and part of a process. Completely locking that down will also lock down creativity. This is what I was talking about in the talk I linked above about balance - going too far on either end will harm the overall process.

Post reply on HN