← Back to context

Comment by jjcm

7 days ago

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: https://youtu.be/Yo7rL0pvHTk?t=147

Our goal is to enable both, not push designers towards one or the other. The author notes:

> You can’t drag things around freely or try odd combinations of layouts. You can’t simply paste something into a frame without it snapping to the bottom of the stack.

What the author is seeing isn't Figma restricting your ability to design, it's other designers adopting it as part of their process. I'd encourage the author to dive into the why of that. What we've found is that often times these structured design approaches can accelerate even freeform design - rarely do you want a menu that doesn't have equal gaps between similar items, so quickly adding that logic can let you move faster. More importantly though, quickly moving past those repetitive parts of the design can let you more quickly focus on the more creative parts.

All that said, these structured approaches can be overbaked, which is what the author might be seeing. Knowing when not to use features such as autolayout can be just as important as knowing how to use them. 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.

Happy to answer any questions about any of this though - this is my bread and butter.

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.

  • > 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.

    • Ah this looks great and exactly what I had in mind - but only available on organization plans.

      Right now I'm generally working with smaller teams/contractors for design stuff (I think this is very common btw that you have one designer and at most a couple of FE engineers actually working on this) - even in larger organisations I've collaborated with doing dev implementation for them I'm not sure many have upgraded to enterprise, but I get a somewhat limited view of Figma from the outside.

      It would be awesome if you could enable this with a limited number of branches or something (even 2 would be a start - master/staging vibes) for pro plans. But I do understand that you need to push people to a higher tier - but I imagine it would really help adoption if I could push back to everyone saying please use branches. It's good to know though for future this exists!

    • As a designer, having the ability to lock certain pages from editing or component updates would get us really far imo. As it stands creating a canonical version requires versioning related components or breaking the component link to prevent inadvertent changes to the design. This could work per-frame as well – if it's 'ready for dev' then it is uneditable and doesn't receive component updates.

>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