Comment by no_wizard
7 days ago
>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
I've never worked in an org where this would be necessary but I can see the use case. If you only want to give your designers building blocks and expect them to use them only, then preventing detach makes a lot of sense.
If there's any flexibility in your designers' work, though, preventing detach would be very frustrating: to create a new thing we'll (designers) often pull from an existing component and detach it in order to harvest it for parts. Not being able to do that would drive me batty.
> 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.
>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
Process is fine, but enforcing process is what is desired. Being able to express constraints globally (IE, organizationally) may limit creativity in an absolute sense, but within constraints you can have your own kind of creativity.
That means not designing features that don't fit within the bounds of a layout for example. Not the easiest to 'process lint', but the tool would know instantly. Thats what I'm talking about. Hand waving that away as a 'process human problem' is disingenuous and I'm rather frustrated thats the response Figma has to this.
So called "dogmatic restrictions" exist for a reason. Though, to say being able to enforce consistency by being able to say, only allow auto layout and associated features, isn't really 'dogmatic'. Just like linters catch features of a language nobody really should use anymore (like JavaScript's `with` for example) is the correct way to solve this problem. Thats not really dogmatic, its just good hygiene.
If Figma doesn't care about any of these real problems, than fine, then make yourself plain and say so explicitly, otherwise the tool has a huge gap in functionality that makes it irritating to actually evolve with.
I imagine this is why Figma has no concept of a staging area either, or a proper VCS, nor a review pipeline, which are also gaps in functionality that would relieve so many issues