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

101–110 of 145 posts

Re: When Figma starts designing us

#101

Post by btown »

PaulHoule wrote: post #40
screye wrote: post #36

Earlier quoted context omitted.

Isn't this the problem with all no-code / low-code platforms ? Code is merely the leanest human-readable representation for loss-less specification of requirements. We're seeing this same pattern with 'K8s YAMLs' and 'prompt engineering'. There is an entire industry that's re-inventing new DSLs which inevitably converge to a scripting language as requirements get more complex. Instead of reinventing the abstraction,…

From my viewpoint the benefit of low-code is that the average business application is a matter of people filling out forms. If you want to radically lower development time you have to solve all the problems https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p... For instance, a 2025 no code platform is likely to have "one click" deployment of a cloud application. That's great if you can accept that but if you…

Change management, designing schemas for being amenable to change management, having systems that can migrate data with an understanding of what historical context in which that data got into the system (was it imported from a source with a nuance that was fine before you changed the form, but now makes less sense with the updated meaning and positioning of the field?)... all of this is what makes software hard, whether low-code or high-code!

One of the ironic things, to bring it back to Figma, is that giving designers and stakeholders Figma in all its glory becomes a justification for having engineers on the project, because you can't realize those exciting design visions with just Airtable and the like. Those engineers aren't useful because they can write code; they're useful because they'll (hopefully!) think through those change management and schema design considerations, building something that will be maintainable in the future. It's a good thing to have a design tool that incentivizes a level of foresight before launching a product that's meant to be best-in-class.

Re: When Figma starts designing us

#102

Post by karaterobot »

> A concrete example is Auto Layout... In practice, this locks the design in place and severely limits the possible expressions. You can’t drag things around freely or try odd combinations of layouts.

I'm a designer, I've used Figma since 2018, and this is incorrect. And not even incorrect in an "I feel differently, but I see what you mean" way. It's the opposite of correct. It's categorically wrong. Autolayout makes it easier to slap layouts together quickly, and change them quickly. The alternative is selecting the object and moving it with the arrows keys, which accomplishes the same thing but is slower, harder, less precise, and worse. It's not creatively empowering to manually align and space objects.

> “Ready for dev” implies that the creation is done and that the developer is merely there to execute the designer’s vision

Don't worry, no engineer I've ever worked with has shared your confusion.

"Ready for dev" is a work management trigger, like closing a ticket—or, more accurately, marking it ready for review. It doesn't mean anything except "this is ready for dev to look at and leave feedback". There is nothing about flagging a section as `ready for dev` that forces engineers to work on it as though it were canon law.

Re: When Figma starts designing us

#103

Post by dandano »

I disagree with this take. I work very closely with my UX lead and we always do lo-fi in Miro/Figjam before hi-fi designs in Figma. This gives us flexibility of expression to quickly mock things up loosely before going into the final design. Auto-layout, components is a huge win for designers. We were on another design product called UXPin which didn't have this sophistication and it was an absolute drag.

Re: When Figma starts designing us

#104

Post by brailsafe »

wx196 wrote: post #26
_bent wrote: post #13

Earlier quoted context omitted.

It doesn't play to the strengths of designers to have them think in terms of Flex layouts and it doesn't play to the strengths of developers to have them translate a design 100% specified to the layout-algorithm and hierarchy of components into code. Yet this is the workflow Figma encourages. What the author encourages is that the designers work more free-flowing with sketches and wireframes and that the developers t…

Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-...

To me, things like mobile-first responsive design and grid-based graphic design thinking are core components of designing for the web, so it's a bit wild to me that Figma, with such popularity, is just now getting grids, and as far as I'm aware no GUI tool has ever succeeded at building a capable visual responsive design tool close to on-par with just designing in the browser.

Re: When Figma starts designing us

#105

Post by asoneth »

travisgriggs wrote: post #69
asoneth wrote: post #16

Earlier quoted context omitted.

> the designer is to dream and your job is to build it You may be thinking of an artist. A designer's job is to understand and solve user problems. (FYI this is coming from a designer, not an engineer.)

Can someone help me understand when this bifurcation happened. As a Mechanical Enginneer who worked their way through college doing software, and then... just kept going for the next 30 years, I find this increasingly role based demarcation difficult to understand/accept. I came out of an era where we called ourselves engineers, but we were designers too. And a whole lot of other things. And the mantra regardless of…

> Can someone help me understand when this bifurcation happened

The distinction is as old as art and design. If I had to pick modern moments that articulated it well I'd go with Arts and Crafts followed by Bauhaus.

> solve the right problem for the right people

Solving problems is the core of design and a design can be evaluated on the basis of how well it solves a problem. Whereas art is free to simply exist. Many works have elements of both, but if you hire someone to solve a problem and they believe their job is to make art then you'll both be disappointed.

I'm unsure what motivated the rest of your post though I can feel your frustration. I will say that bureaucracies and processes have been around for centuries, they just shift language every decade or so. There has also always been a tension between the people who Do and the people who Decide but both are necessary for a functional organization.

Re: When Figma starts designing us

#106

Post by markbao »

karaterobot wrote: post #102

> A concrete example is Auto Layout... In practice, this locks the design in place and severely limits the possible expressions. You can’t drag things around freely or try odd combinations of layouts. I'm a designer, I've used Figma since 2018, and this is incorrect. And not even incorrect in an "I feel differently, but I see what you mean" way. It's the opposite of correct. It's categorically wrong. Autolayout makes…

I don’t see how it could be categorically wrong. To me it’s categorically right: Auto Layout specifically is intended to restrict the possible layout options.

You trade off adding limitations for how much you can do in a design and move things around freely, and in return you gain more convenience and less work needed to organize designs. You can change designs around quickly… as long as they’re within the rather confined limitations of Auto Layout.

I think the fundamental disagreement is that one person sees creative empowerment as freedom from doing busywork, whereas another (including the author) sees it as freedom to experiment with a design without limits. Neither is inherently wrong, but the two are inherently in conflict.

Re: When Figma starts designing us

#108

Post by BoorishBears »

sumeruchat wrote: post #5

Engineers here will disagree of course but the job of the designer is to dream and your job is to build it

The first thing I did was search for the definition of art you're working with

What I found looked like a page that 4.1 nano (not even mini) would come up with, so I'm not sure where this energy is coming from

Re: When Figma starts designing us

#109

Post by gyomu »

cosmic_cheese wrote: post #47
miiiiiike wrote: post #10

No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…

As a dev that does a lot of his own design, I’ve never really understood the need to build a full fidelity reproduction of the layout systems a design is targeting. The limitations and considerations involved are deeply internalized and for the most part, I know exactly where designs tend to break and how to account for them. The layout system is effectively running in my head the entire time I’m mocking things up. S…

> I’ve never really understood the need to build a full fidelity reproduction of the layout systems a design is targeting.

Well, you wrote why right before:

> As a dev that does a lot of his own design

You understand the whole, so you don't need lossy abstractions to connect the ends. When roles are specialized and people only understand part of the context in which they're working, they need ways to communicate about the whole thing.

Tools like Figma fill those sort of gaps, that tend to occur in organizations with dozens/hundreds of employees, with the need to quickly onboard frequent new hires, etc.

Re: When Figma starts designing us

#110

Post by ripped_britches »

I would agree but this is an organizational issue, not a Figma issue.

This is endemic to corporate engineering culture.

You can tell because they/us layer even more nonsense atop these Figma features like multiple composed layers of design tokens.

I literally had a design manager ask if we need a token for full opacity. Let that sink in for a second… A variable to represent something with 0% transparency. Under what circumstance would that possibly be useful?

Post reply on HN