Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Figma starts designing us

designsystems.international

Post reply on HN
Print view View original

91–100 of 145 posts

Re: When Figma starts designing us

#91

Post by no_wizard »

jjcm wrote: post #90
no_wizard wrote: post #85

Earlier quoted context omitted.

>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…

> 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 a…

>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

Re: When Figma starts designing us

#94

Post by H1Supreme »

zelphirkalt wrote: post #20

It is a shame, that so few designers actually know the medium they are working with well, let alone the primitives, that they are operating on top of (CSS layouts). If they did, I think we would have many less shitty website designs. Personally, I would expect someone who calls themselves a "web designer" to know HTML and CSS of course, and in a more or less up to date fashion. Well, not really would expect, but woul…

How many web designer (ie. strictly HTML + CSS) roles are out there anymore? Anytime a position is posted with "HTML and CSS" in the requirements, you can almost guarantee a Javascript framework of some sort is in there as well.

Re: When Figma starts designing us

#95

Post by martinald »

jjcm wrote: post #89
martinald wrote: post #87

Earlier quoted context omitted.

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 intenti…

> 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 nu…

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!

Re: When Figma starts designing us

#96

Post by radley »

quacked wrote: post #72
radley wrote: post #42

Earlier quoted context omitted.

That has nothing to do with Figma. That's all due to Jony-Ive-Deiter-Rams cargo-cult design thinking. I think liquid glass will remedy that specific issue (while introducing all new ones...)

Really? Every Figma mockup I've ever seen appears to be imitating that exact style. I don't think I've ever seen something different from any Figma product, even in their own advertisements. I thought it was a classic case of the tool/process constraining the design outputs, like those 5-over-1 designs that every new apartment building looks like.

Designers were doing minimalism before they were using Figma. Figma is just a tool that spawned in the middle of the minimalism cargo-cult era.

FWIW, minimalism was a super-convenient solution that helped developers avoid responsive skeuomorphism. The issue at hand is simply due to designers who poorly execute minimalism, either through ignorance or fanaticism. It's kinda like people who still, enthusiastically, stand in line for new iPhones.

Re: When Figma starts designing us

#97

Post by drewbeck »

jjcm wrote: post #89
martinald wrote: post #87

Earlier quoted context omitted.

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 intenti…

> 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 nu…

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.

Re: When Figma starts designing us

#98

Post by ricardobeat »

H1Supreme wrote: post #94
zelphirkalt wrote: post #20

It is a shame, that so few designers actually know the medium they are working with well, let alone the primitives, that they are operating on top of (CSS layouts). If they did, I think we would have many less shitty website designs. Personally, I would expect someone who calls themselves a "web designer" to know HTML and CSS of course, and in a more or less up to date fashion. Well, not really would expect, but woul…

How many web designer (ie. strictly HTML + CSS) roles are out there anymore? Anytime a position is posted with "HTML and CSS" in the requirements, you can almost guarantee a Javascript framework of some sort is in there as well.

That’s not the point - it’s been at least a decade since “web designer” means doing graphic/interaction design, and not coding in HTML and CSS.

What they are saying is that, in the same way a car designer cannot do a great job without having decent knowledge of aerodynamics and the physics involved, good design for the web requires some understanding of the underlying technologies.

Re: When Figma starts designing us

#99

Post by drewbeck »

no_wizard wrote: post #85
jjcm wrote: post #50

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: http…

>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…

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.

Re: When Figma starts designing us

#100

Post by pcurve »

Lalabadie wrote: post #38

I'm seeing lots of opinions from people in different roles who wish Figma would serve them , but I agree with the author. Assuming Figma is meant to serve the design process, it tries to stretch far into implementation territory, but does it at the expense of the exploratory phase. Everything Figma adds either screams MAKE IT READY FOR DEV or GET ALL YOUR MANAGERS A FIGMA SEAT™. Those are not concerns for the early e…

Figma has neglected its core audience - the designers.

Instead, it is trying to be all things to everyone, except it's serving no on well at this point.

And it all started with FigJam. Still a half-baked product trying to take piece of pie from Miro.

Then they released Dev Mode to extract more revenue. Now Figma Sites to compete against web build/hosting sites.

So many half baked products, it's frustrating. They're abusing their monopolistic position in the market.

there will be a time where they'll have to pull a Google and retire products that never worked out.

Post reply on HN