I don’t agree with the overarching theme of „structure over spontaneity“. Some of the most impactfull print designs of the past started with „structure“ or some orher sort of „form follows function“.
When Figma starts designing us
111–120 of 145 posts
Re: When Figma starts designing us
#112> 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…
> Don't worry, no engineer I've ever worked with has shared your confusion.
I have seen nontechnical product managers share this confusion to the strong detriment of projects.
Re: When Figma starts designing us
#113I'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…
Unless you're building content-marketing or similar- you don't need a lot of the exploratory phase to be done freeform. Trying to implement designs in a product where every single new design stretches or modifies the design system is mind bogglingly annoying as a developer, especially if you've got a small team trying to crank out new features. We don't need a tenth variation of a call to action, we don't need to use…
Exploratory design isn't for crafting padding overwrites and call to action tweaks...
It's for thinking from first principles about the problems users face, and how to shape the products we create to best help those users overcome their problems. This means reconsidering faulty assumptions about the nature of the problem users face & the shape of the product that best solves that problem.
I hate this shift of the role of design in software towards trivial aesthetic fixations.
Design should be a shared discipline that orients product development towards greater value for users, but as of late it's mostly a trendy & low value extension of marketing.
Re: When Figma starts designing us
#114No, 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…
I haven't used it myself yet, from what I've heard, Penpot is closer to filling that gap? https://penpot.app
And it's free and open source.
Re: When Figma starts designing us
#115As a once full-time designer turned full-time engineer, I totally agree with the author.
There are plenty of other more creative design tools - but Figma's success and ubiquity have locked many organisations into more limited, sometimes formulaic and un-creative design expressions.
Also, I unfortunately don't feel that this is the ideal forum for this idea to get much support.
Re: When Figma starts designing us
#116No, 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…
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,…
> I'd like to see no-code UX patterns that losslessly map onto the underlying abstraction. That way you can use the UX pattern until it gets too tedious, and occasionally dip in-and-out of the code-view in a non-jarring manner.
What are you describing sounds a lot like Saleforce and other CRM systems. Often the code implementation get hidden away when it's not something native in the no-code solution. Then "magic" happens and you don't quite know why until you dig into the code again.
Re: When Figma starts designing us
#117Earlier 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…
> Another example that kept turning up was that the ticket "1 phone number for a customer is not enough, support 2 phone numbers" is inevitably followed by "2 phone numbers is not enough, support 3 phone numbers"
Zero. One. Infinity.
https://en.m.wikipedia.org/wiki/Zero_one_infinity_rule
YAGNI, handle a singular case, and once you have multiple treat it like a list.
Re: When Figma starts designing us
#118> 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 am not using Figma at all. Not a designer, and I know CSS, at least the part I am using and am not afraid of looking into it more when I need more. For example recently I wanted a grid layout, that has at maximum 2 columns and wraps to 1 column when not sufficient space for both columns is available, so I looked up how to do that.
"Ready for dev" -- If we expand that abbreviation, then it would be "ready for development" or "ready for developer", so the actual literal meaning to me seems to be: "Now you can show this to a developer so that they can _properly_ develop it." and not "Now put this onto your production website, you are done!"
Might be that many people get confused though.
Re: When Figma starts designing us
#119No, 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…
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,…
>Code is merely the leanest human-readable representation for loss-less specification of requirements.
I think you might have meant "loss-less specification of the current design." requirements are aspirational, and signifies the intent, code is the loss-less version of how the system will actually behave.
Re: When Figma starts designing us
#120Earlier quoted context omitted.
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…
>> an object going through a number of states with state transitions was general and much better than the 15+ date columns It amazes me that anyone would write a schema with a dozen date columns, but I've seen such things. Once you're dealing with a large database of something like that, it's tempting to just add one more column rather than pitch why you should refactor the whole thing. I try to keep my schemas relat…
I've made automated form editors, companies I've worked for have done it. They had data nesting, with no custom functions for handling it. For example I've made a fully customisable menu editor where you could add sections, sub sections, prices to items, prices to sub items, prices for picking 2 out of X items in the menu. All sorts of crazy (optional) nesting. All saved in different tables. Took me like 2 weeks. I felt very clever at the time. Frontend was all in jQuery too!
They all saved to relational databases with multiple tables. One form editor (which wasn't mine), allowed you to add new columns (this was in the on-prem days and back then they avoided future collisions by prefixing the custom columns with ex_).
The problems you listed above are solveable. You don't need custom functions, you need clever property naming. Most ORMs have to solve them too.
So nested data is not actually a problem for lo-code solutions, it's a solvable/solved problem.
And I STILL regularly leave that sort of data denormalized. I write multiple date columns (e.g. created, lastUpdated, etc.). I still write mobile + work numbers as columns for plenty of apps.
Why? It's simple YAGNI. For many apps it's quicker and easier to denormalize the data and keeps the code much, much simpler.
Plenty of apps that I've seen that have been going 15+ years haven't normalized that data and it's fine.
The problem comes when no-one refactors and keeps adding them.
But it's extra work and it's "dangerous" work, potentially data destroying if you get it wrong.
You get no thanks, as other devs will moan it's more complicated to use, and if you slip up you might get fired.
So most devs take the easier and safer option and just add a new column.