Guesstimate: the % of time you spend actually designing or product managing / (divided by) % 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.

@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 )