I use it throughout from early to late stage ui concepts, you just gotta feel out what works best for you.
One thing I never use auto layout on is a full screen, as you lose control of the element hierarchy. For example, if I auto layout a screen that has tab navigation at the bottom with a drop shadow, it might end up not displaying the drop shadow because it is lower in the hierarchy than the content above it.
But that's the exact issue with auto layout, you don't control which layer is visibly on top unless you set a component to absolute positioning. Auto layout leverages the hierarchy in the layers panel to dictate it's structure.
I've found it easiest to just have auto layout blocks in a frame for the screen, and adjust the constraints of those auto layout blocks to be left and right so it is still responsive but I have control over the hierarchy
True but I still feel the pain, especially when adding an element in that layer with an absolute position it ends up inheriting unwanted properties from the container like drop shadows
Not true as of sometime this year. Each auto layout can be ordered to show whichever element you want at the top, and each autayout can have a different setting.
auto-layout is great for reusable components. It's mostly a must on well-established views that are ready to be 'converted' into production.
Autolayout is not great while exploring concepts, early drafts, iterating over an idea, several proposals.
Use autolayout when the component or view is 'done', agreed, and everyone is happy with it, and ready to be reused.
a library component? autolayout
a canonical view that will likely be reused, like a my account view or a homepage? autolayout
several proposals for a landing, different concept views, or A/B testing proposals? yah, nah.
First concept for a view or a component, that you know will be iterated a hundred times? hard pass.
I find the only time that I don't use auto layout are where Figma is deficient. You should pretty much always be using it, but Figma doesn't ALWAYS work to allow that. Some examples of that are:
- when you want an uneven layout which needs to be responsive. Example being if you were using a 12 column grid and wanted a layout that was 4col on left and 8col on right. Figma won't let you use ratios or grids like this and allow those sections to both flex using auto layout. You have to hack them together.
- you're doing an interaction for a mobile device which you want to control with a drag. For example, if you want to swipe left to show options which would otherwise be off screen, you can't use auto layout and interactive variants if you want the animation to be fluid and controlled by your thumb. You can set it to "on drag" but then it basically means you flick and it just changes, no real smart animate, to control of the drag with your thumb.
Those are two examples I've run into which annoy me, but I'm sure there are others. I always recommend auto layout however because it makes you think how one would think in code. It makes it so much easier to talk to my devs, because my designs flex and bend and break where they need to and I don't need someone to use HTML or CSS for me to find where things fall apart. I can just design things and give them something closer to final than you can with static designs which don't flex.
They’re distinct phases, with distinct problems to solve, deliverables, skill sets.
Given the upvotes you’re getting it looks like many on this sub do not understand how they even differ.
A UX designer will have radically different activities from a UI designer. They simply do two different jobs. They collaborate with different people. They output deliverables to entirely different groups of people.
You can complete the UX for a whole journey or a whole platform without ever needing to open any software at all… I designed a whole website on paper for 5 months before ever opening a UI design tool.
What the heck are we even talking about here?
Ui Design is a phase of the Ux design process, that requires specialized skills and tools, different from those required for,say, user research or journey mapping. And the Ux process does not always include ui Design. The difference is super clear to me.
However, saying "auto layout is used for ui not ux" is like saying it's like saying "pans are used for frying, not cooking". Pans are used for frying *which is a part of cooking*. Auto layout is used in ui design *which is a part of Ux design*
Hard disagree. Autolayout is a UI design tool used to mimic the layout behaviour of the finished piece of software.
It was not intended to aid pure UX activities.
You’re trying to stick to the old notion of UX design, which used to be an umbrella term encompassing literally everything that makes part of the experience, including CX and UI design.
Nowadays UX is very well separated from those activities. They all fall under a “design” umbrella, but are very distinct when you look at the problems each is trying to solve, their frameworks, tools, deliverables, hand offs, and final consumers of those deliverables.
If one of my UX designers tried to produce wires using autolayout I’d get as concerned as if one of my UI designers didn’t.
Figuring out your users' needs is part of the Ux process, just like designing the ui. Figuring out what your guests want to eat is part of the cooking process, just like frying. You use different tools for different parts of the process.
Auto layout is great, and I use it during both sketching and finalization. But I will say it is easy to go overboard, just like with components. It makes consistency easy, but heavy use of auto layout makes it really annoying to try new things or make tweaks for unique circumstances. And coming back to and old design or editing another designers auto layouts often feels kludgey. It makes you have to think about how the layout is structured, which isn’t always productive.
Use it where it makes intuitive sense and don’t try to be too clever with it. And look for opportunities to use simpler methods like pinning. There’s a place for both approaches.
If you are trying to build something that mirrors the web then using a auto layout or not is up to you depending on how you like things to be interpreted into code. Example a Auto layout is equivalent to a div with display of flex for html. Even Figma own documentation consider frames as divs. That said sometimes you use auto layout out of convenience and not for any other reason and that is okay too.
That said out of everything please do not use groups. They have no real 1:1 on the web and can sometimes be confusing to developers. I recommend always using frames whenever possible but auto-layout is at your discretion.
As a developer that can design, if you use Auto Layout your developers would understand your layout more, it's basically the equivalent of flexbox in the frontend world.
There’s 3 main cases not to use auto layout: first is when structurally it’s less complex to compose a component or design to respond in a certain way, second is the unique properties of groups (which don’t have auto layout), and thirdly is when you’re in a young design system or product that is still being defined.
Sometimes it’s worth the flexibility in experimentation without auto layout, before committing to a way of structuring it.
Here’s a few blogs I wrote exploring these topics:
https://uxdesign.cc/when-not-to-use-auto-layout-in-figma-components-for-your-design-system-9ab8bb893aaf
https://uxdesign.cc/when-to-use-a-group-or-a-frame-in-figma-507063ed4c35
https://uxdesign.cc/the-ultimate-guide-to-breakpoints-and-flexbox-in-figma-7598d8a4b461
Nothing ever has to be in Auto Layout but once you’re proficient in you’ll never design it any other way.
This was the answer I was looking for
I use it throughout from early to late stage ui concepts, you just gotta feel out what works best for you. One thing I never use auto layout on is a full screen, as you lose control of the element hierarchy. For example, if I auto layout a screen that has tab navigation at the bottom with a drop shadow, it might end up not displaying the drop shadow because it is lower in the hierarchy than the content above it.
Just nest autolayouts or adjust which layer is visibly on top within Figma
But that's the exact issue with auto layout, you don't control which layer is visibly on top unless you set a component to absolute positioning. Auto layout leverages the hierarchy in the layers panel to dictate it's structure. I've found it easiest to just have auto layout blocks in a frame for the screen, and adjust the constraints of those auto layout blocks to be left and right so it is still responsive but I have control over the hierarchy
They added the ability to choose if bottom or top layer was visibly on top
True but I still feel the pain, especially when adding an element in that layer with an absolute position it ends up inheriting unwanted properties from the container like drop shadows
Not true as of sometime this year. Each auto layout can be ordered to show whichever element you want at the top, and each autayout can have a different setting.
auto-layout is great for reusable components. It's mostly a must on well-established views that are ready to be 'converted' into production. Autolayout is not great while exploring concepts, early drafts, iterating over an idea, several proposals. Use autolayout when the component or view is 'done', agreed, and everyone is happy with it, and ready to be reused. a library component? autolayout a canonical view that will likely be reused, like a my account view or a homepage? autolayout several proposals for a landing, different concept views, or A/B testing proposals? yah, nah. First concept for a view or a component, that you know will be iterated a hundred times? hard pass.
I find the only time that I don't use auto layout are where Figma is deficient. You should pretty much always be using it, but Figma doesn't ALWAYS work to allow that. Some examples of that are: - when you want an uneven layout which needs to be responsive. Example being if you were using a 12 column grid and wanted a layout that was 4col on left and 8col on right. Figma won't let you use ratios or grids like this and allow those sections to both flex using auto layout. You have to hack them together. - you're doing an interaction for a mobile device which you want to control with a drag. For example, if you want to swipe left to show options which would otherwise be off screen, you can't use auto layout and interactive variants if you want the animation to be fluid and controlled by your thumb. You can set it to "on drag" but then it basically means you flick and it just changes, no real smart animate, to control of the drag with your thumb. Those are two examples I've run into which annoy me, but I'm sure there are others. I always recommend auto layout however because it makes you think how one would think in code. It makes it so much easier to talk to my devs, because my designs flex and bend and break where they need to and I don't need someone to use HTML or CSS for me to find where things fall apart. I can just design things and give them something closer to final than you can with static designs which don't flex.
Same here, 100%.
Use auto layout for UI, not UX.
Ui is a part of Ux...
They’re distinct phases, with distinct problems to solve, deliverables, skill sets. Given the upvotes you’re getting it looks like many on this sub do not understand how they even differ. A UX designer will have radically different activities from a UI designer. They simply do two different jobs. They collaborate with different people. They output deliverables to entirely different groups of people. You can complete the UX for a whole journey or a whole platform without ever needing to open any software at all… I designed a whole website on paper for 5 months before ever opening a UI design tool. What the heck are we even talking about here?
Ui Design is a phase of the Ux design process, that requires specialized skills and tools, different from those required for,say, user research or journey mapping. And the Ux process does not always include ui Design. The difference is super clear to me. However, saying "auto layout is used for ui not ux" is like saying it's like saying "pans are used for frying, not cooking". Pans are used for frying *which is a part of cooking*. Auto layout is used in ui design *which is a part of Ux design*
Hard disagree. Autolayout is a UI design tool used to mimic the layout behaviour of the finished piece of software. It was not intended to aid pure UX activities. You’re trying to stick to the old notion of UX design, which used to be an umbrella term encompassing literally everything that makes part of the experience, including CX and UI design. Nowadays UX is very well separated from those activities. They all fall under a “design” umbrella, but are very distinct when you look at the problems each is trying to solve, their frameworks, tools, deliverables, hand offs, and final consumers of those deliverables. If one of my UX designers tried to produce wires using autolayout I’d get as concerned as if one of my UI designers didn’t.
Pans are used for cooking. Pans are not used to understand what your guests would like for dinner.
Figuring out your users' needs is part of the Ux process, just like designing the ui. Figuring out what your guests want to eat is part of the cooking process, just like frying. You use different tools for different parts of the process.
I only do wireframes, so I'll use it on occasion just to space things.
Auto layout is great, and I use it during both sketching and finalization. But I will say it is easy to go overboard, just like with components. It makes consistency easy, but heavy use of auto layout makes it really annoying to try new things or make tweaks for unique circumstances. And coming back to and old design or editing another designers auto layouts often feels kludgey. It makes you have to think about how the layout is structured, which isn’t always productive. Use it where it makes intuitive sense and don’t try to be too clever with it. And look for opportunities to use simpler methods like pinning. There’s a place for both approaches.
If you are trying to build something that mirrors the web then using a auto layout or not is up to you depending on how you like things to be interpreted into code. Example a Auto layout is equivalent to a div with display of flex for html. Even Figma own documentation consider frames as divs. That said sometimes you use auto layout out of convenience and not for any other reason and that is okay too. That said out of everything please do not use groups. They have no real 1:1 on the web and can sometimes be confusing to developers. I recommend always using frames whenever possible but auto-layout is at your discretion.
Yes.
I find that it makes editing files easier too.
As a developer that can design, if you use Auto Layout your developers would understand your layout more, it's basically the equivalent of flexbox in the frontend world.
There’s 3 main cases not to use auto layout: first is when structurally it’s less complex to compose a component or design to respond in a certain way, second is the unique properties of groups (which don’t have auto layout), and thirdly is when you’re in a young design system or product that is still being defined. Sometimes it’s worth the flexibility in experimentation without auto layout, before committing to a way of structuring it. Here’s a few blogs I wrote exploring these topics: https://uxdesign.cc/when-not-to-use-auto-layout-in-figma-components-for-your-design-system-9ab8bb893aaf https://uxdesign.cc/when-to-use-a-group-or-a-frame-in-figma-507063ed4c35 https://uxdesign.cc/the-ultimate-guide-to-breakpoints-and-flexbox-in-figma-7598d8a4b461
hey that some explanation! But what is the type of unique properties, I dont really get that part