Guesstimate: the % of time you spend actually designing or product managing / (divided by) % of time trying to get Figma to work

Starting to feel Components and Autolayout and Prototying and Variables and Styles are just gigantic time sinks.

I would guess I’m 20% / 80%. 20% of time actually doing work, 80% of time trying to get Figma to work.

@Michael_Staton hello! just curious - mind expanding more on how components/autolayout/prototyping are negatively impacting your design time? You mentioned you spend a lot of time trying to get things to work – can you give examples on what you’ve run into?

I can pass feedback on to our product team with the details – I maybe can help with some suggestions as well.

Why yes I can and you can tell Kris and Dylan I say hello and am ranting on their community board.

I need to do actual work today so I will be brief and come back to you with more. I will start with things that might actually be quick fixes rather, and gradually work towards epic never going to happen things.

So, off the top of my head:

  1. Once you make something a Component, the little purple component Icon takes over and you no longer know if it is an Autolayout, a Frame, or a Group. Not a problem at first, but if you are REALLY committed to components you will nest components inside components inside components inside components. You will have one component made of 50 other components.

But then your design isn’t behaving the way you want, you have to go into every thing that could be causing some glitch. It’s usually some Fill vs Hug vs Fixed fiasco with Autolayout. Though more and more I’m running into Frames and Groups (and Groups inside Frames) that are automatically set to Left and Top constraints, and need to be set to Scale and Scale.

But, because the little purple diamond of death is just a purple diamond, you have to click through every one to see which Frame or Autolayout setting in which nested component is the obstacle to responsive layouts. Then when you find it, for Frames and Groups you cannot change its Constraints from where you are, you must go to the SOURCE component (usually in the design system file).

Now wait just a minute, yes you think you found the problem. But, it’s a nested component!!! So then you must go to the source of that. And that YES it’s in your Design System, but it’s on another page. It’s on your Containers and Wrappers Page. So then you go back to the Design you are working on (but actually you might not even remember where that was, or if you are ADHD like me you totally forgot what you were trying to do in the first place.

Okay so your back to your design. And it turns out that IT DIDN’T FIX THE PROBLEM. You go back to your Containers and Wrappers, nope that’s fine. Oh wait, it’s the ICON. Yes it’s the ICON! The Icon is a Group (but you don’t know it is because of the purple diamond and it is not on Scale Scale, it is on Bottom Right. WHO DID THAT! (Hint, it was me. Two weeks ago.).

@ksn So for this one, I have one quick fix a few gigantic things that may never happen:

  1. The purple diamond is cool, but your little autlayout, frame, and group Icons should be in it somehow. I should just be able to look through the left hand navigation to see that, not follow the neverending “Go to main component” “Go to main component” scavanger hunt.

  2. (harder) make it so that you can change the Constraints of the child instance object (an instance of another component) within a parent Component.

  3. (harder) make it so that you can change the constraints the entire stack of NESTED objects from the parent layer. You can change it for multiple objects that are peers by selecting them all. But you can’t in one fell swoop set the constraints of everything to Scale Scale (which is a super frequent bug, I’m trying to scale up a component.)

  4. (probably really hard) Every component anywhere gets two locations for the “main component” – the source of truth. One is wherever we put it in our design files. The other is in a completely opinionated Component Library that Figma creates for every File and every Team. The entire point is to have them in Alphabetical order, (maybe you could sort them by other conditions) but that way when you are in Nested Component Hell, you don’t end up jumping across files and pages and sections. They’re all there in one place. So if you have to traverse 10 different components to find the source they are all there. Maybe it’s just a pop out of the asset library on the left column that allows you to edit components without the jumping.

  5. (probably really hard) You have a “Debug” interface, similar to IDEs. If I’m in a component that have a bunch of layers of nested components, and it’s not behaving how it should, I can press “debug” and it will have some fancy column or row of all components in the component tree, and all of their properties are there in one view you can scroll up and down or left to right.

@ksn here is the file and component tree for the component above:





Holy moly, mate… Is there a particular reason to componentize that much? With no context it seems like a bit of over engineering to me. I’d rather not to have all these container components, if you care about consistency just use design tokens. There was a very important statement that you have “very opinionated” components in your DS, but there is another way of doing stuff for sure. I’d do it like the TailwindCSS way, which is way more agile

@Pavel_Kiselev @ksn well first I’m not generally “the designer” – I’m more “the compiler” – and I thought the whole point of components is that you can propagate changes throughout all your files? So, anything of decent importance that might show up in 3 or more files, often 3 or more times in each file, I assumed that was like the whole point of components? Sorry if I sound a little valley girl.

Also, I’ve never read or seen anything regarding best practices with components. How big should they get?

My take is as follows: anything that either 1) is a token that has a meaningful impact on the style, 2) any designed object that is likely to be used and reused, or will likely end up in several Design Files multiple times, 3) any designed object that has been “finalized” and entered the UI Kit of engineering, 4) meta-objects used for documentation (therefore needs to be used and reused AND will end up in many Design Files and Pages.

@Pavel_Kiselev and @ksn , Here watch me be totally unable to debug one simple component: I want to adjust the size of the bullet icon in a bullet point. I want to make it 24x24 instead of 32x32.

Notice how I don’t have access to the width and height fields.

I mean, I can go create a variant, but then I have to manage that. Usually, I can scale a component object if it is set to scale scale in the main component, and this is.

I would like to get a response on this particular case. However, it’s representative of how I find myself increasingly spending my time. To the point where I feel like I’m not doing the work I’m supposed to be doing.

2024-02-10 21.29.18

Seems like a learning curve issue to me mate. I’d do it a bit differently for your specific example with the “Bullet_Row” thing. For me, it seems like a very common UI pattern. It’s a text label accompanied by either leading or/and trailing icons. And you want to be able to resize icons with little to no effort. I would use a few key ingredients here.

  1. Icon image component, you can use whatever imagery you have, just make sure it does scale properly when you resize it.
  2. Size token component that sets a scale ramp for your icons, bullets whatever.

Size token is a key here.

I made a simple rect and set its size with a variable, you can “hardcode” it though. Then I wrap it with Auto Layout frame that hugs the sizing element. This is important because only auto-sized elements will be able to change their size when you swap instances. Repeat multiple times for multiple sizes you want to support.

Here is what I got for my needs

Then I combine an icon with the size token into a generic icon component with two properties.

image

As you can see the size of the component is set with size token. The image is sitting in absolute positioned frame that grows/shrinks with the main component.

image

I use the icon property to swap the image and the size property to swap the size token.

Finally, I combined the generic icon component with a text layer to make a text label component

Here is how it works

1 Like

@Pavel_Kiselev first, thanks so much for being thorough in your response. I don’t generally have good luck with forums, it’s very rare that someone actually tries to help and can (outside of Stack Overflow). So, really, thanks. Also, your community “playground” file has some interesting components. So, I shall be stealing some. And, I like the way you do sizing. I tool your advice:

BUT… lol

I know it’s easy to make a variant set at various rem, em break points. That’s super necessary in some situations. I have these below.

However, in quite a few situations that I run into every day, I just need to adjust the size of something and I can’t. And, the nested properties stack is painful to debug. So, I’m not arguing with you as much as saying: I can agree that variant sets with sizing are a best practice and I should stop praying for features.

But, Figma is almost painfully un-opinionated. It’s a blank canvas. People are going to be using it in different ways, and Figma is a classic “expand the market” strategy. Their growth from here forward is going to come from non-designers needing to use Figma, or from people starting their career in design or product choosing to use Figma. So, the “novice” user experience is important for their long term strategy. Classic The Innovator’s Dilemma.

Even if you have identified a best practice, I still think this whole – can I resize, can I not, can I set the properties up and down the object tree from an easy to access place, etc, is still something a large number of people could benefit from. I haven’t spent too much time on this forum, but I’ve already seen multiple posts of people confused about the behavior of autolayout, frames, components, and their intersection.

Well, for me this is the whole point of the standardized image component and the size token underneath. This way you define images that are predefined to have certain sizes, on a scale you wouldn’t want everything to be any size as you try to fit everything into a system.

IMO my technique makes memory efficient components that are easier to maintain as I don’t have to repeat myself repeatedly to support sizes on various images here and there. I’d prefer not to do this →

I can see at least 3 component sets with 4 image sizes which are the same. I am too lazy to maintain it )

Can you clarify how you do it? Sorry to be obtuse.

I also want to be lazy. Why do you think I do all this work to try to use components?

Do you have any specific questions? I feel like I provided fair bit of details here :arrow_right: Guesstimate: the % of time you spend actually designing or product managing / (divided by) % of time trying to get Figma to work - #9 by Pavel_Kiselev

What would you like to clarify?

Okay, so here’s a second much easier one to digest and potentially do something about.

I’m often needing to stretch a gradient over a series of shapes or components. Like this:

I can do this two ways. I can systematically take the start and end point for the nested shape or component, and make Styles for each. It’s really painstaking and then if you want to change the angle or points of the gradient, you then have to redo every single one. This gradient and shape combo is supposed to represent three weeks and 19 days. So, changing the “parent” gradient will then require changing 19 gradients.

That sucks, so I choose a faster route. I can create a frame the dimensions of the container of this series, and then flatten all the nested shapes… and I can fill the frame with the gradient and then use mask.

That looks cool.

But the problem is then one of further manipulation. First, I had to flatten all of the nested shapes. So, that can be limiting by itself. For instance, at certain dimensions I want to be able to change the corner radius. Second, I can’t export as an SVG and keep the mask (and more importantly neither can my engineers.).

For the record, this is what an SVG export looks like of this object:

And if I flatten, both the gradient layer and the mask layer, I lose the gradient. Here’s an attempt at me using every type of boolean operation:

2024-02-27 19.12.02

@Pavel_Kiselev again, thank you for your time and thought. If you’re still paying attention, I’m not sure I can clarify but I will try.

It seems instead of trying to resize nested instances and frames and groups and autolayout containers you simply create an array of size variants upon developing the component. So, a few questions arise when I’m thinking about our workflow:

  1. how do you name sizes to make sense to your remote team? Do you have a convention that works for you?

  2. How do you manage ambient awareness within your team if you or someone changes a nested object? So, say the linework stroke is too big. You want to go reduce the line size. How does this change then propagate throughout your designs? If you’re not propagating changes through the Component publish and update feature, how are you making others aware and assuring org wide design standards? Or do you then change the stroke on all of your variants across all sizes?

I’m not sure if those questions are clear or not. But this is the complexity overkill that goes through my head.

This one seems easier to address :slight_smile:

Here you go - https://www.figma.com/file/YunsCn3An0HeBnDD3xAQoD/Fixed-Background-Hack?type=design&node-id=0%3A1&mode=design&t=3I7IdxhqCx84je4K-1

And it is much much easier in CSS - https://codepen.io/oxn-krtv/pen/bGJbjWN

how do you name sizes to make sense to your remote team? Do you have a convention that works for you?

it’s all about defining some design tokens in the first place. t-shirt size, indexed whatever.
something like

and then you apply them to graphical objects to fit their size into the standard.

for dynamic nested instances, I use the technique described above

How do you manage ambient awareness within your team if you or someone changes a nested object?

it depends. if that’s a custom artwork and the way for your team to get it via export then who cares what you did to it to make it work? you just export an asset with all the amendments you made

if it is a standard graphics object, component-like and you have an instance with amendments and these amendments are envisioned in code, then you have to document it. something like “This is Image A with a thinner stroke on layer F”