Live data from Hacker News

Will Figma become an awkward middle ground?

dive.club

21–30 of 134 posts

Re: Will Figma become an awkward middle ground?

#21
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

Agreed that in most cases all this extra work and attention to detail is essentially wasted effort that never sees the light of day. But it’s possible to extract value from it if you have a culture where designers build prototypes, and you can use those prototypes for user testing, feedback, demos and pitches, while the code is being built. But it’s rare that companies have this culture.

Really good (and underdiscussed) point that Figma designs are not just for consumption by developers.

I know this is a cliche phrase, but when you're trying to align stakeholders (PM, manager, VP, dev lead) on a product, it is genuinely very useful to have really nice, hi-fi mockups to make sure everyone is talking about exactly the same stuff.

It's also definitely a scale thing. If you have 500 developers, it's probably worth putting in some extra sweat just to make sure they're all using the exact same button, etc

If you have 10 devs... yeah, hard to justify a super-perfectly-polished design system for every single bit of your frontend, IMO.

Re: Will Figma become an awkward middle ground?

#23
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

> There's way too much to do with media break points As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier. It easily snowballs into you having 3 different CSS (phone/tablet/desktop). I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window…

If you want responsive page elements that change styling as you reflow the page, we have that now - container queries - https://developer.chrome.com/blog/css-ui-ecommerce-cq but it's still somewhat new, and nobody's existing design systems support them yet. People (myself included sometimes) still prefer using JavaScript for this stuff. It'll change over time, though. (Also I've been wishing for this for almost two decades now, so I'm glad to see it arrive!)

Edit: Though even simpler than that is the width media query, which I think you might be looking for: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/widt...

Re: Will Figma become an awkward middle ground?

#24
As someone who develops email templates, you will never understand my pain. Figma creates a complete fantasy world for designers who do not understand that a pixel and color perfect design is going to be smashed to bits by the client.

Also, I feel the rise of React is partially to blame. CSS frameworks were clunky and constraining - but they forced you into a lot of design constraints developed on years of best practices. I can't tell you the number of React-based enterprise tools I have to use on a daily basis that have picture-perfect designs ... that turn clunky and confusing the minute you resize the window or activate an animation.

Re: Will Figma become an awkward middle ground?

#25
Slightly off-topic, but I dislike this trend of "designers over-designing everything". This website is aesthetically pleasing, and has it's own unique style, but scrolling the home-page is laggy on my $4,000 Macbook (Chrome). I guess it's because it downloads 14MB of resources and tries to download more based on scroll position?

Re: Will Figma become an awkward middle ground?

#26

Earlier quoted context omitted.

> There's way too much to do with media break points As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier. It easily snowballs into you having 3 different CSS (phone/tablet/desktop). I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window…

If you want responsive page elements that change styling as you reflow the page, we have that now - container queries - https://developer.chrome.com/blog/css-ui-ecommerce-cq but it's still somewhat new, and nobody's existing design systems support them yet. People (myself included sometimes) still prefer using JavaScript for this stuff. It'll change over time, though. (Also I've been wishing for this for almost two d…

Thanks for sharing.

I've just found that approach very clunky in practice, hence my comment about it snowballs into effectively having 3 different CSS (phone/tablet/desktop) and wrapped in media width queries.

Though maybe I use it incorrectly.

I'm always open to learning something new :)

Re: Will Figma become an awkward middle ground?

#28

Figma is a tool and nothing more, despite some people to turn it into the end all be all of user experience. It will eventually be replaced with something, just as it replaced Sketch, and just like Sketch replaced Illustrator. I also noticed that the author barely touches on the people who make the interfaces (product designers). If the author gets their wish, businesses won't hesitate to axe their UX teams to save s…

author here I'm also a product designer! I'm skeptical of the current approach to AI-generated interfaces. But am a big believer that AI will fundamentally change the way we design products.

My high-level hypothesis is that in the same way browser-based design (Figma) displaced Sketch... code-based design will displace Figma. It will start with the longtail and smaller teams. Figma has a stranglehold on enterprise. But I refuse to believe I will be making vector pictures of products in the longrun. It will feel as easy to design interfaces in code. The article is an attempt at discouraging text-based prompting in that world though. I'd much rather have a modern sketching/wireframing tool connected to my code base and design system.

Re: Will Figma become an awkward middle ground?

#29

How shitty is Figma’s current “export as css/html/js” functionality? How many people do you think they have working on improving that? How many of the people Figma is paying to fool around with AI do you think are experimenting with building an AI stuffed full of css/html/js tokens, and other functionality for improving Figma’s ability to pick up working css/html/js, tweak it, and re-export it?

How incentivized is Figma to invest in a world where fewer developers pay for seats is the real question

Re: Will Figma become an awkward middle ground?

#30

Earlier quoted context omitted.

If you want responsive page elements that change styling as you reflow the page, we have that now - container queries - https://developer.chrome.com/blog/css-ui-ecommerce-cq but it's still somewhat new, and nobody's existing design systems support them yet. People (myself included sometimes) still prefer using JavaScript for this stuff. It'll change over time, though. (Also I've been wishing for this for almost two d…

Thanks for sharing. I've just found that approach very clunky in practice, hence my comment about it snowballs into effectively having 3 different CSS (phone/tablet/desktop) and wrapped in media width queries. Though maybe I use it incorrectly. I'm always open to learning something new :)

Well, I'm not sure of other syntaxes to make it simpler, but you could use a CSS variable to make it a little easier: https://developer.mozilla.org/en-US/docs/Web/CSS/var Especially if you re-use the same padding values for multiple parts of the page/site. Then you won't have to update values in 3 different places for each padding/font-size/whatever rule. Instead just set the variable for each @media width and then in your later rules, use the single variable to refer to the correct value for all breakpoints.

Also, some units cascade. So if you set the top-level or parent to a particular size, then child elements inside can inherit (or ignore) the unit. This means at a top level you can set your font-size for each @media width, and then use relative units and it will inherit down. But that only works for very small websites, because it introduces subtle bugs as you incorporate more controls from people not aware of your particular practice.

Post reply on HN