When Figma starts designing us(designsystems.international)
designsystems.international
When Figma starts designing us
https://designsystems.international/ideas/when-figma-starts-designing-us/
144 comments
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.
Graph UI for manipulating git trees (gitgraph) is a great example. Orchestration UI views (Airflow / Langraph) are another example that's getting there. At a higher level of abstraction, Notion (CRDT UIs) do a good job of representing collaboration-locks using blocks. At the highest view, I'm a big fan of how Gather-town represents remote collaboration.
I'd like to see more of this.
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.
Graph UI for manipulating git trees (gitgraph) is a great example. Orchestration UI views (Airflow / Langraph) are another example that's getting there. At a higher level of abstraction, Notion (CRDT UIs) do a good job of representing collaboration-locks using blocks. At the highest view, I'm a big fan of how Gather-town represents remote collaboration.
I'd like to see more of this.
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 require "on prem" this is either disqualifying or requires you to build an environment on prem that can host whatever it is they generate, which could be more trouble than building an application the old fashioned way in an environment you already know how to run.
A conventional analysis is that you should be able to generate a CRUD application out of a schema: you need a little bit more than something that looks at a SQL schema and creates a form to INSERT, UPDATE or DELETE, but that's a start.
One problem is that people write schemas that suck despite there being a body of "commonsense knowledge" about how to the world works. I had a year when I fixed a tremendous number of broken applications and one insight I got out of that was that whether it was a student who went from being an applicant to being enrolled to being an alumni or a pallet that would live in a logistics network and then enter a "reverse logistics" network and be inspected and possibly repaired to be returned to the logistics network the same data model of an object going through a number of states with state transitions was general and much better than the 15+ date columns that were added haphazardly to those columns.
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" -- it saves time to work the proof by induction up front and just support N phone numbers up front. But talk that way and people think you're a lunatic like Doug Lenat.
Deployment, code generation from schemas, and schema generation from meta-schemas are part of the solution but if you can't solve 100% now getting that last bit is ultra-hard mode because all the essential complexity hidden by the framework is suddenly in your face.
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 require "on prem" this is either disqualifying or requires you to build an environment on prem that can host whatever it is they generate, which could be more trouble than building an application the old fashioned way in an environment you already know how to run.
A conventional analysis is that you should be able to generate a CRUD application out of a schema: you need a little bit more than something that looks at a SQL schema and creates a form to INSERT, UPDATE or DELETE, but that's a start.
One problem is that people write schemas that suck despite there being a body of "commonsense knowledge" about how to the world works. I had a year when I fixed a tremendous number of broken applications and one insight I got out of that was that whether it was a student who went from being an applicant to being enrolled to being an alumni or a pallet that would live in a logistics network and then enter a "reverse logistics" network and be inspected and possibly repaired to be returned to the logistics network the same data model of an object going through a number of states with state transitions was general and much better than the 15+ date columns that were added haphazardly to those columns.
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" -- it saves time to work the proof by induction up front and just support N phone numbers up front. But talk that way and people think you're a lunatic like Doug Lenat.
Deployment, code generation from schemas, and schema generation from meta-schemas are part of the solution but if you can't solve 100% now getting that last bit is ultra-hard mode because all the essential complexity hidden by the framework is suddenly in your face.
> 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.
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.
In the case of the phone number or email it is just so frickin' predictable what will happen.
Adding multiple non-list fields is seductive because going to the list is a "structural instability" that requires using different coding techniques.
Right now I really like https://www.react-hook-form.com/ for forms that have list values. Back in the day there were a set of techniques that seem forgotten (like how the Egyptians built the pyramids) that some developers knew and others didn't.
It isn't hard at all to make a no-JS form where you had an "add" button next to a list of values. When you click on that button the POST data contains everything in the form as well as the key/value pair for that particular button (and not other buttons) so the back end can tell which button was pressed and redraw the form with another field. Delete can be handled the same way. If your form is not junked up with 50MB of trackers and ads and metadata for every social platform it is really fast, it was really fast even on dialup.
With a handful of helper functions and a "router" that can display different forms depending on what you enter you can make powerful no-JS forms but that knowledge didn't quite reach 100% penetration before Angular came along, but developers who came on after that never learned it.
Adding multiple non-list fields is seductive because going to the list is a "structural instability" that requires using different coding techniques.
Right now I really like https://www.react-hook-form.com/ for forms that have list values. Back in the day there were a set of techniques that seem forgotten (like how the Egyptians built the pyramids) that some developers knew and others didn't.
It isn't hard at all to make a no-JS form where you had an "add" button next to a list of values. When you click on that button the POST data contains everything in the form as well as the key/value pair for that particular button (and not other buttons) so the back end can tell which button was pressed and redraw the form with another field. Delete can be handled the same way. If your form is not junked up with 50MB of trackers and ads and metadata for every social platform it is really fast, it was really fast even on dialup.
With a handful of helper functions and a "router" that can display different forms depending on what you enter you can make powerful no-JS forms but that knowledge didn't quite reach 100% penetration before Angular came along, but developers who came on after that never learned it.
I must say, React Hook Form offers a good way for React to interact with forms. There are many things to dislike in that ecosystem but that lib is excellent.
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.
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.
>> 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 relational as possible. Actions and immutable records should obviously be stored in separate tables from the objects they reference. However, this does make the UX form design / CRUD process less amenable to simple solutions where forms are just generated right out of a schema.
Your phone number example highlights this. In general of course you want to store contacts in a separate table from customers. But that means you're probably going to need a separate contacts sub-form within your customer form, rather than just inline phone fields. Then form will need to be required or inlined for any new customer before the main customer form can be saved. Stuff like that.
Over the last 15 years or so I've built and refined my own form generator, really a DSL for designing forms that fit this type of thing. In its more basic use cases, each form lives as a row in a database, with each form_item linked to it in a separate table. The form runs a pre-fab query that expects N inputs that it binds to :variables (usually in WHERE or HAVING clauses) and then renders a pre-populated visual form with various input types like dropdowns, checkboxes, calendars, etc (based on those form_items, which can all be styled, required/not required, required based on other answers, etc). Each form_item has its own standard validation or custom validation function on both the client and server side. The form knows which table it wants to write to and which bound variable is the id field it's going to target for update. Sending it a blank id field renders the form with nothing populated and then does an insert instead of an update when it's submitted. It's very slim, about 500 LOC of Typescript and 700 LOC of PHP, including most standard kinds of validations on both ends. I've always toyed with the idea of releasing it it for people to use, but here's the rub: If you want to do anything involving writing to more than one table, you need to write a custom final function for those additional insert/updates.
So, it's a lovely system, but someone coming to it naively would run the risk of designing schemas that were not expressive enough, to try to keep the CRUD system happy. And I think this is just an inevitable problem with all low-code solutions: They don't handle multi-dimensional data the way you want a clean schema to handle it. (And neither do users).
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 relational as possible. Actions and immutable records should obviously be stored in separate tables from the objects they reference. However, this does make the UX form design / CRUD process less amenable to simple solutions where forms are just generated right out of a schema.
Your phone number example highlights this. In general of course you want to store contacts in a separate table from customers. But that means you're probably going to need a separate contacts sub-form within your customer form, rather than just inline phone fields. Then form will need to be required or inlined for any new customer before the main customer form can be saved. Stuff like that.
Over the last 15 years or so I've built and refined my own form generator, really a DSL for designing forms that fit this type of thing. In its more basic use cases, each form lives as a row in a database, with each form_item linked to it in a separate table. The form runs a pre-fab query that expects N inputs that it binds to :variables (usually in WHERE or HAVING clauses) and then renders a pre-populated visual form with various input types like dropdowns, checkboxes, calendars, etc (based on those form_items, which can all be styled, required/not required, required based on other answers, etc). Each form_item has its own standard validation or custom validation function on both the client and server side. The form knows which table it wants to write to and which bound variable is the id field it's going to target for update. Sending it a blank id field renders the form with nothing populated and then does an insert instead of an update when it's submitted. It's very slim, about 500 LOC of Typescript and 700 LOC of PHP, including most standard kinds of validations on both ends. I've always toyed with the idea of releasing it it for people to use, but here's the rub: If you want to do anything involving writing to more than one table, you need to write a custom final function for those additional insert/updates.
So, it's a lovely system, but someone coming to it naively would run the risk of designing schemas that were not expressive enough, to try to keep the CRUD system happy. And I think this is just an inevitable problem with all low-code solutions: They don't handle multi-dimensional data the way you want a clean schema to handle it. (And neither do users).
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.
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.
> Code is merely the leanest human-readable representation for loss-less specification of requirements.
Hum... That's assuming you have a perfect development stack that hides all non-essential complexity.
And well, I have news for you, that's a low-code platform. A generic stack that hides every problem but solves every requirement just can't exist.
Hum... That's assuming you have a perfect development stack that hides all non-essential complexity.
And well, I have news for you, that's a low-code platform. A generic stack that hides every problem but solves every requirement just can't exist.
While code may no be the leanest human-readable representation, scripting languages are a quite deep local minimum. There is a difference between hiding complexity and blocking you off from complexity. Scripting languages work because when you encounter a problem your library / framework can't fix, there is at least a basic procedural Turing complete language to fall back on.
> 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.
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.
>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.
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.
No, I meant requirements.
Stated otherwise: "Sufficiently advanced requirements are indistinguishable from code".
Abstracted requirements define outcomes. Fine-grained requirements define code.
Stated otherwise: "Sufficiently advanced requirements are indistinguishable from code".
Abstracted requirements define outcomes. Fine-grained requirements define code.
I respectfully disagree.
The customer has given a requirement that states the variable <y> has to be calculated as y= x +1.
However, the code that exists has been implemented such that <y> is calculated as y= x - 1.
y=x-1 is how the current system behaves. However it conflicts with the actual requirement, which is y=x+1.
The customer has given a requirement that states the variable <y> has to be calculated as y= x +1.
However, the code that exists has been implemented such that <y> is calculated as y= x - 1.
y=x-1 is how the current system behaves. However it conflicts with the actual requirement, which is y=x+1.
Regardless of whether or not the code is correct, it's still defining the behavior of the system.
If the customer would like to describe the ideal behavior of the system, the only way is to translate it into code.
If the customer would like to describe the ideal behavior of the system, the only way is to translate it into code.
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.
So while it’s nice to have tools to help with menial bits like correct spacing, getting every little behavior right in the mockup feels a lot like unnecessary busywork.
Naturally things are a bit different in a team setting, because it can’t be assumed that everybody involved has this level of knowledge/experience, but well… maybe it’s not crazy to expect designers to carry this set of skills, and it’s perhaps not a good thing for parties outside of design and engineering to be able to easily poke and prod at designs directly. Having the design team as a required intermediary helps sanity check changes.
So while it’s nice to have tools to help with menial bits like correct spacing, getting every little behavior right in the mockup feels a lot like unnecessary busywork.
Naturally things are a bit different in a team setting, because it can’t be assumed that everybody involved has this level of knowledge/experience, but well… maybe it’s not crazy to expect designers to carry this set of skills, and it’s perhaps not a good thing for parties outside of design and engineering to be able to easily poke and prod at designs directly. Having the design team as a required intermediary helps sanity check changes.
I had my UX designer girlfriend read “CSS: The Definitive Guide” and it changed the way she looked at her job. She taught me Figma and it changed the way I look at my job, and hers.
Learn as much as you can. Specialization is for insects.
Learn as much as you can. Specialization is for insects.
What did you learn about Figma that changed how you think about your work?
I advocate for learning as much as possible as well. It comes naturally with being self-taught. That said I think it’s also worth zooming out and giving things a look through a critical eye to ensure that the things we’re learning are necessary and worthwhile.
There are still a number of “old school” UI designers out there who’ve resisted trends and have staunchly stuck to a more traditional workflow, where they start out with a rough mockup made in e.g. Photoshop and then iterate the design alongside an engineer. It would be interesting to be in the room amidst a discussion between one of these traditionalists and a “new age” Figma-type UI designer.
There are still a number of “old school” UI designers out there who’ve resisted trends and have staunchly stuck to a more traditional workflow, where they start out with a rough mockup made in e.g. Photoshop and then iterate the design alongside an engineer. It would be interesting to be in the room amidst a discussion between one of these traditionalists and a “new age” Figma-type UI designer.
> 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.
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.
Yep.
Back in the 1990s there was a huge influx of people into web design who knew how to design for print at a "retail" level (design an ad or a poster) as opposed to a "wholesale" level (create a design system for a magazine) and as a dev I would frequently receive a PSD from a designer and figure out how to abuse the primitive HTML was had then to make something that looked like that.
Today Figma has replaced PSD but the same pathologies remain. A new version of iOS comes out and the armchair quarterbacks want to go over the appearance pixel by pixel but they're not really interested in UX design in the sense of designing a sequence of interactions to attain a goal.
As a dev, what I want from designers is design systems, guidance on what everything is supposed to look like that I can implement whatever I need to implement and have it look like a designer was involved. I blame the tools though less than I blame the designers who are just not inclined to think systematically. CSS was definitely designed to create design systems (css classes used in a disciplined way reflective of semantics) but tools like bootstrap, tailwind, Emotion, and the MUI theming system all represent regressions away from that ideal but I don't think those tools make bad designers, it's the other way around.
Back in the 1990s there was a huge influx of people into web design who knew how to design for print at a "retail" level (design an ad or a poster) as opposed to a "wholesale" level (create a design system for a magazine) and as a dev I would frequently receive a PSD from a designer and figure out how to abuse the primitive HTML was had then to make something that looked like that.
Today Figma has replaced PSD but the same pathologies remain. A new version of iOS comes out and the armchair quarterbacks want to go over the appearance pixel by pixel but they're not really interested in UX design in the sense of designing a sequence of interactions to attain a goal.
As a dev, what I want from designers is design systems, guidance on what everything is supposed to look like that I can implement whatever I need to implement and have it look like a designer was involved. I blame the tools though less than I blame the designers who are just not inclined to think systematically. CSS was definitely designed to create design systems (css classes used in a disciplined way reflective of semantics) but tools like bootstrap, tailwind, Emotion, and the MUI theming system all represent regressions away from that ideal but I don't think those tools make bad designers, it's the other way around.
This! It is bad enough that most designers think they are UX experts too (few of them are), but trying to micromanage devs so that every screen would be "pixel perfect" really takes the cake. Especially when the provided designs (that should be followed religiously) are missing core functionality and the whole flows. Just give me the guidelines please, and please please be consistent with them!
Well, I'm sure they have their own set of gripes about the developers too. ;-)
Well, I'm sure they have their own set of gripes about the developers too. ;-)
> If you need a free form design tool to sketch, use one. There are hundreds of them.
Before Figma, the norm of design tool was Photoshop, not the other "hundreds of them."
So go back in time, if you had been Figma founder developing a tool that appeals to most designers, it should've looked more like Photoshop than like CSS/HTML.
Before Figma, the norm of design tool was Photoshop, not the other "hundreds of them."
So go back in time, if you had been Figma founder developing a tool that appeals to most designers, it should've looked more like Photoshop than like CSS/HTML.
Fireworks also existed the whole time which had a lot of Figma's features but bizarrely was completely ignored by 95% of designers.
I used Fireworks a lot, and what amazed me at Sketch when I found it, is that they figured out every single thing that bothered me in Fireworks and did it right. At that period, Figma was mostly copying all the tiny clever innovations done by Sketch.
There is the sketch app , which is older and more of a direct competitor to Figma. Figma won because of being web based/ multi platform among other advantages.
Exactly this. Thank you.
We need a Blender-like design tool specifically for product design. Using HTML/CSS for rendering so it covers most web needs and that usually more than encompasses native app-layout emulation. Open source, technical, and not expected to be picked up in a day or fully understood top-to-bottom by everyone.
The reason Figma is putting us into a design box is because it doesn't have all the CSS features that actually let you create incredible experiences.
We need a Blender-like design tool specifically for product design. Using HTML/CSS for rendering so it covers most web needs and that usually more than encompasses native app-layout emulation. Open source, technical, and not expected to be picked up in a day or fully understood top-to-bottom by everyone.
The reason Figma is putting us into a design box is because it doesn't have all the CSS features that actually let you create incredible experiences.
as much as folks hate electron, I think if Figma was electron, it would at least have the entire chromium web engine to work with
Figma on desktop is an Electron app I believe. Figma chose to build a custom webGL rendering engine for their design canvas, so the core issue is that technical decision early on (probably allowed for some better performance and multiplayer back then). Figma is stuck with wanting to control their rendering and allow for non-product stuff like Figjam or the new Draw tools, but it will inherently hold them back from providing a really good design/dev handoff and always will hold designers back because it doesn't use CSS web rendering.
I’m actively working on an alternative right now. It’s a tool for designing in the browser, using HTML and CSS. Everything is parametric by design, including tokens.
Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.
Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.
Yeah we need that... and more HTML it is, the better.
That would be awesome,
Looking forward to it.
Thanks, I can’t wait to showcase it on here. It’s frustrating because I can only work on it on nights and weekends, and my 15 month old daughter doesn’t make that any easier.
I’m incredibly pumped for it, though. It’s almost entirely keyboard driven, kinda like Vim. I’m building this rich set of mnemonic commands to build/design UI components. It’s like Vim + Storybook + WebFlow.
I’m incredibly pumped for it, though. It’s almost entirely keyboard driven, kinda like Vim. I’m building this rich set of mnemonic commands to build/design UI components. It’s like Vim + Storybook + WebFlow.
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.
And it's free and open source.
"the problem is that it’s too designer-y for engineers"
Exactly! Numerous times I have wanted to start a new personal project however got stuck in figma designing process. Had no other chance except writing in pure html/css - the only things that still "work" for me unlike those stupid frameworks.
Exactly! Numerous times I have wanted to start a new personal project however got stuck in figma designing process. Had no other chance except writing in pure html/css - the only things that still "work" for me unlike those stupid frameworks.
I think the authors point, is that, designers are incorrectly choosing the wrong tool.
In my experience in FAANG, designers use Figma for everything. Like literally everything.
So when you say, they should use a sketch tool when they need free form, they don’t
In my experience in FAANG, designers use Figma for everything. Like literally everything.
So when you say, they should use a sketch tool when they need free form, they don’t
So one of my teams was struggling with Figma to work with users. Then someone had the bright idea to just prompt an LLM to generate code for the mock UI and made it happen in 2 days. Far better user experience.
I'm late to reply, but check out Plasmic. We often get the complaint that we're too engineer-y instead of designer-y, so it might work for you.
> If there’s something better than Figma out there, please, let me know.
HTML+CSS works very nice for these mock-ups. Tried Figma and Sketch for a small project, never again.
HTML+CSS works very nice for these mock-ups. Tried Figma and Sketch for a small project, never again.
Yeah...
Just do pictures on the design phase and then code.
Just do pictures on the design phase and then code.
There’s a lot that goes into creating the pictures. Consistent spacing, colors that change depending on platform, breakpoints, containers, and on and on and on.
There’s no reason that a tool can’t model a design system and make producing consistent designs that use it trivial.
I think the problem with Figma is that it tries to appeal to visual designers, UX designers, and programmers. Good for business, bad for users.
There’s no reason that a tool can’t model a design system and make producing consistent designs that use it trivial.
I think the problem with Figma is that it tries to appeal to visual designers, UX designers, and programmers. Good for business, bad for users.
Don't create every possible picture. Create a representative set.
Draw each screen at least once. If you have dark mode, you don't have to fully redraw each screen in dark mode, just enough to show how dark mode should look. If it has to work on desktop, you probably do have a completely different desktop version of each screen (from the default mobile) so draw that - but don't redraw every detail of a widget that's identical to mobile.
Testing every combination should be for the testing stage. It's good if you can foresee clashes (like the desktop version of this widget looks bad on this page in dark mode) in the design stage but it's not really an excuse to prolong the design so long that it lasts until you would have been finished with testing anyway.
Having a computer generate all the combinations for you in the design stage isn't that great unless you can pay individual attention to them - there's no point producing artefacts that nobody looks at.
Draw each screen at least once. If you have dark mode, you don't have to fully redraw each screen in dark mode, just enough to show how dark mode should look. If it has to work on desktop, you probably do have a completely different desktop version of each screen (from the default mobile) so draw that - but don't redraw every detail of a widget that's identical to mobile.
Testing every combination should be for the testing stage. It's good if you can foresee clashes (like the desktop version of this widget looks bad on this page in dark mode) in the design stage but it's not really an excuse to prolong the design so long that it lasts until you would have been finished with testing anyway.
Having a computer generate all the combinations for you in the design stage isn't that great unless you can pay individual attention to them - there's no point producing artefacts that nobody looks at.
I don't think you got the point. Instead of "pictures" we need a design system - defined sizes, paddings, margins, grids, font-sizes, colors, breakpoints, variants, components, behaviors, transitions, etc. and it should be consistent across the app. How many times have I worked with a design that didn't respect these consistently from page to page...
Instead of pictures or a design system, what you need is a way for users to do stuff with your app. Pictures help with this more than a design system does. More important than every margin being the same across the app, is being able to do stuff with the app. The consistent margins can come later, once the app does useful stuff.
Are you saying thread product is laggy or your development process? If it's the latter, you sure youdont just need to update your computer?
No. It's just not implemented in a way that would let it support a large design system, even on a 16-core machine with 128GB of RAM.
So, I’m not familliar with whatever Figma’s Auto Layout is, but the complaint still feels somewhat wrongheaded.
Design ≠ print design; if you’re designing for a reflowable medium, you’ll have to design to its constraints. A good prototyping tool should allow you to go outside the constraints for the moment, but for a web or mobile designer to dismiss those constraints as the engineer’s concern is about as appropriate as for a typographer to dismiss the constraints of type casting as the moldmaker’s: it won’t work.
Design ≠ print design; if you’re designing for a reflowable medium, you’ll have to design to its constraints. A good prototyping tool should allow you to go outside the constraints for the moment, but for a web or mobile designer to dismiss those constraints as the engineer’s concern is about as appropriate as for a typographer to dismiss the constraints of type casting as the moldmaker’s: it won’t work.
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 take over earlier to bring that into a workable structure. And that the collaboration between designer and developer doesn't stop at an async hand-off, but that they finalize the design together -- in code.
Some of the commenters here seem to be annoyed at designers that make "hard to implement designs" and therefore think they want designers to constrain everything with auto layout. But this doesn't address the cause of the issue, which is designs being made by designers in isolation, which are then being treated as gospel for developers to 100% match. This is the real problem.
In my opinion the gravest issue with Figma encouraging this workflow is actually the feature gap. Figmas feature set is extremely underpowered in comparison to CSS. Figma doesn't even have grids. If designers are now building stuff only with the tools that Figma allows, all the cool and creative ideas that developers could bring in, because they are actually pretty easy to implement on their platform (the designer just doesn't know about it) will go away.
I can only recommend you this talk by Matthias Ott: https://www.youtube.com/watch?v=1Pq7VqNrtk4
What the author encourages is that the designers work more free-flowing with sketches and wireframes and that the developers take over earlier to bring that into a workable structure. And that the collaboration between designer and developer doesn't stop at an async hand-off, but that they finalize the design together -- in code.
Some of the commenters here seem to be annoyed at designers that make "hard to implement designs" and therefore think they want designers to constrain everything with auto layout. But this doesn't address the cause of the issue, which is designs being made by designers in isolation, which are then being treated as gospel for developers to 100% match. This is the real problem.
In my opinion the gravest issue with Figma encouraging this workflow is actually the feature gap. Figmas feature set is extremely underpowered in comparison to CSS. Figma doesn't even have grids. If designers are now building stuff only with the tools that Figma allows, all the cool and creative ideas that developers could bring in, because they are actually pretty easy to implement on their platform (the designer just doesn't know about it) will go away.
I can only recommend you this talk by Matthias Ott: https://www.youtube.com/watch?v=1Pq7VqNrtk4
Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-...
now to get designers to actually use these things.
Figma has a bunch of good tooling, but getting designers to use it, and use it consistently, is the real problem.
Designers exist in a realm seemingly, where outside pressure can't really be put on it from an organizational level to get them to uniformly adopt a set of standards they will always adhere to. Every company I have worked at, big, medium, small, seems to have this problem
Figma has a bunch of good tooling, but getting designers to use it, and use it consistently, is the real problem.
Designers exist in a realm seemingly, where outside pressure can't really be put on it from an organizational level to get them to uniformly adopt a set of standards they will always adhere to. Every company I have worked at, big, medium, small, seems to have this problem
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.
This does not seem that surprising to me.
Browsers are by and large black boxes—less because of their architecture and more because of the sheer size of the code, although Firefox, for example, seems to have been moving towards a less open architecture for most of its history as well (deCOMtamination, death of XULRunner, Quantum, etc.).
What you really want in a parametric web design tool is to crack open the layout engine and the CSS cascade and inheritance, at the very least. That’s a lot of work to target a demographic of designers and programmers who by now have largely decided to ignore CSS in favour of reinventing inline styles badly (Tailwind) and insert markup as necessary for the desired visual effect. (Is there a tool to do CSS in terms of React/etc. components, with proper cascading, custom pseudoclasses and pseudoelements and so on? I haven’t seen one.)
Browsers are by and large black boxes—less because of their architecture and more because of the sheer size of the code, although Firefox, for example, seems to have been moving towards a less open architecture for most of its history as well (deCOMtamination, death of XULRunner, Quantum, etc.).
What you really want in a parametric web design tool is to crack open the layout engine and the CSS cascade and inheritance, at the very least. That’s a lot of work to target a demographic of designers and programmers who by now have largely decided to ignore CSS in favour of reinventing inline styles badly (Tailwind) and insert markup as necessary for the desired visual effect. (Is there a tool to do CSS in terms of React/etc. components, with proper cascading, custom pseudoclasses and pseudoelements and so on? I haven’t seen one.)
This is absolutely correct in this case. Figma Auto Layout is just a simplified version of Flexbox, and it's purpose is:
1. To adjust to size changes
2. To avoid having to manually position things in a row or column
1. To adjust to size changes
2. To avoid having to manually position things in a row or column
An innovative custom designer can use other tools or do manual animations / layout if they require.
It's absolutely trivial to make any element ignore the auto-layout grid.
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 exploration and research stage. If Figma is one of the first tools I boot up in my design process, I'm immediately running into a conflict of priorities.
I put it in contrast with old-school Photoshop UI work (younger devs: yeah, it was pretty much the one option, plus the only thing taught at design schools). Photoshop was great at the exploratory phase. I would sketch ideas with my Wacom tablet and eventually translate hand-drawn wireframes to actual mockups. I still miss that workflow, it was great. The tradeoff then was that "final" documents were static, fixed dimensions documents that usually left technical issues to be discovered later during the dev stage.
Photoshop shaped the design process just as much as Figma does now. That's what the readily available tool does to someone using it regularly.
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 exploration and research stage. If Figma is one of the first tools I boot up in my design process, I'm immediately running into a conflict of priorities.
I put it in contrast with old-school Photoshop UI work (younger devs: yeah, it was pretty much the one option, plus the only thing taught at design schools). Photoshop was great at the exploratory phase. I would sketch ideas with my Wacom tablet and eventually translate hand-drawn wireframes to actual mockups. I still miss that workflow, it was great. The tradeoff then was that "final" documents were static, fixed dimensions documents that usually left technical issues to be discovered later during the dev stage.
Photoshop shaped the design process just as much as Figma does now. That's what the readily available tool does to someone using it regularly.
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 a new, tenth shade of blue or green for just this one place, we don't need a twentieth exception to the existing padding rules. If it is one size on desktop and another in mobile everywhere else, then those are how the sizes should change in this new feature too.
Once you've got a design language in place, leave it alone unless the change to the semantics is meaningful and consistent.
Having done the slice and dice of Photoshop files in years gone past, I'm very glad we have better tools for collaboration now.
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 a new, tenth shade of blue or green for just this one place, we don't need a twentieth exception to the existing padding rules. If it is one size on desktop and another in mobile everywhere else, then those are how the sizes should change in this new feature too.
Once you've got a design language in place, leave it alone unless the change to the semantics is meaningful and consistent.
Having done the slice and dice of Photoshop files in years gone past, I'm very glad we have better tools for collaboration now.
These are complaints about the designer you are working with and the deliverables they're choosing to give you, are they not?
Figma isn't/shouldn't be the arbiter of what's possible in the project, that's a major point of the article.
My role as a designer is to explore options and _then_ narrow down to a sensible solution (diamond-shaped process, etc etc). My developer colleague is concerned by the second part of that process, and I should make sure to provide her with consistency and sensible use of exceptions. That doesn't change my responsibilities to the exploratory part, and I can't exclude it from my consideration when choosing and critiquing tools.
Figma isn't/shouldn't be the arbiter of what's possible in the project, that's a major point of the article.
My role as a designer is to explore options and _then_ narrow down to a sensible solution (diamond-shaped process, etc etc). My developer colleague is concerned by the second part of that process, and I should make sure to provide her with consistency and sensible use of exceptions. That doesn't change my responsibilities to the exploratory part, and I can't exclude it from my consideration when choosing and critiquing tools.
>These are complaints about the designer you are working with and the deliverables they're choosing to give you, are they not?
It is, to some degree, but the tools don't help any related party enforce consistency that will translate to the broader output of that work, that doesn't help matters very much.
In addition, designers themselves by and large don't seem to care enough about consistency like this. Engineers have design systems (ideally) that they pull from, but I'm still shocked in 2025 there is no good 1-1 communication of imposing the constraints of a design system in the designer <> engineer workflow.
Not to mention, for every designer I know that does adopt features of the tool that make this easier, like auto layout, there's a much greater number of designers that refuse to use them.
Seemingly, engineers hold themselves to a higher standard of consistency than designers do. I've seen this pattern too many times and its the only reasonable conclusion I've been able to draw. I was even hired to help streamline engineering and design work together and share as much as possible to get a corporate design system adopted, and I always had a hell of alot more resistance and argument with the design side of that equation on this.
edit: after seeing someone from Figma comment, I feel its unlikely it will ever have any of these types of features, which is a shame
It is, to some degree, but the tools don't help any related party enforce consistency that will translate to the broader output of that work, that doesn't help matters very much.
In addition, designers themselves by and large don't seem to care enough about consistency like this. Engineers have design systems (ideally) that they pull from, but I'm still shocked in 2025 there is no good 1-1 communication of imposing the constraints of a design system in the designer <> engineer workflow.
Not to mention, for every designer I know that does adopt features of the tool that make this easier, like auto layout, there's a much greater number of designers that refuse to use them.
Seemingly, engineers hold themselves to a higher standard of consistency than designers do. I've seen this pattern too many times and its the only reasonable conclusion I've been able to draw. I was even hired to help streamline engineering and design work together and share as much as possible to get a corporate design system adopted, and I always had a hell of alot more resistance and argument with the design side of that equation on this.
edit: after seeing someone from Figma comment, I feel its unlikely it will ever have any of these types of features, which is a shame
Agreed 100%. This op-ed on a site called design systems is ironic.
The purpose of design systems is for visual consistency. If someone needs to freehand some ideas, bust out a blank sheet of paper or Illustrator, but when designing a new page for a app, we want all that baggage of existing components and layouts.
The purpose of design systems is for visual consistency. If someone needs to freehand some ideas, bust out a blank sheet of paper or Illustrator, but when designing a new page for a app, we want all that baggage of existing components and layouts.
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.
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.
Visual design, interactive design and information architecture are all lumped together under UX, but there's little call for going back to first principles when you have an established design system.
When you do, you end up with prototypes that are disconnected from what exists, and don't look good when you actually start using the existing visual design system. That's where all the one-off tweaks start coming in.
Unless the business is willing to pay for research into a holistic change to the semantics of the existing design system, Figma is perfectly suitable for the majority of design work once a cohesive design language has been put together.
When you do, you end up with prototypes that are disconnected from what exists, and don't look good when you actually start using the existing visual design system. That's where all the one-off tweaks start coming in.
Unless the business is willing to pay for research into a holistic change to the semantics of the existing design system, Figma is perfectly suitable for the majority of design work once a cohesive design language has been put together.
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.
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.
Having designed websites with Dreamweaver, Photoshop, Illustrator and Sketch, I absolutely love Figma and especially Auto Layout. I don't think people realise how annoying it was to design a list of repeatable items. There already was a concept of "smart object" or "component" that could be duplicated in instances with variations. But laying them out was really cumbersome: if one of the instance had a different height, it would mess up the design because all subsequent items would need to be repositioned. The gap between them was also not a value: it was just space that wasn't used, so you couldn't interact with this gap.
Auto Layout fixes all those issues: you have a list of items of variable height with a fixed gap. You can very easily add/remove/reorder items, without breaking your design. You can even make it wrap, with different column and row gaps, and thus replicate a flexbox layout with "flex-wrap: wrap".
Each item can either hug its contents, have a fixed width, or grow. That's essentially flex-shrink and flex-grow in Figma. So useful.
You'll also notice that prototypes have a "responsive" mode, and it's amazing how Auto Layout will easily adapt to _any_ screen dimension. If you create a data table with one column that "fills" the space, you have a responsive prototype right out of the box.
Also, you can now drag an Auto Layout and it will fill it with component instances and replace its text content, essentially allowing you to fill your design in seconds. Incredible.
If the author still wants to manually place frames around, they still can. Just use fixed dimensions frames, with fixed positioning. That's similar to using "position: absolute" in your CSS. It's just a different type of design. Nothing forces you to use Auto Layout.
Auto Layout fixes all those issues: you have a list of items of variable height with a fixed gap. You can very easily add/remove/reorder items, without breaking your design. You can even make it wrap, with different column and row gaps, and thus replicate a flexbox layout with "flex-wrap: wrap".
Each item can either hug its contents, have a fixed width, or grow. That's essentially flex-shrink and flex-grow in Figma. So useful.
You'll also notice that prototypes have a "responsive" mode, and it's amazing how Auto Layout will easily adapt to _any_ screen dimension. If you create a data table with one column that "fills" the space, you have a responsive prototype right out of the box.
Also, you can now drag an Auto Layout and it will fill it with component instances and replace its text content, essentially allowing you to fill your design in seconds. Incredible.
If the author still wants to manually place frames around, they still can. Just use fixed dimensions frames, with fixed positioning. That's similar to using "position: absolute" in your CSS. It's just a different type of design. Nothing forces you to use Auto Layout.
I'm glad to see that someone else took issue with the Auto Layout part of this article. The shape, text, and grouping tools are all there and nothing is stopping anybody from using them to create new interfaces that have approximately zero auto snapping.
I loved Illustrator way way back in the day when I was a poor student with a cracked version. I found it so easy to use!
Design software nowadays... oh boy
Design software nowadays... oh boy
Completely agree with the author.
> This is contrary to my belief that any digital design process should start with rough sketches, but move quickly into code and iterate from there.
As a dev, this is the point I resonate with the most.
To me, the ideal dev <> designer interaction is collaborative and iterative. But the current state of affairs is one where all the design is done upfront, and little is done in terms of explaining why some choices were made. Mockups are not a good medium to spark discussions in the team, because developers are left in the dark about intent.
> This is contrary to my belief that any digital design process should start with rough sketches, but move quickly into code and iterate from there.
As a dev, this is the point I resonate with the most.
To me, the ideal dev <> designer interaction is collaborative and iterative. But the current state of affairs is one where all the design is done upfront, and little is done in terms of explaining why some choices were made. Mockups are not a good medium to spark discussions in the team, because developers are left in the dark about intent.
Ditto.
To me, one of the dirtiest words in dev <> designer interaction is "handoff". There's always a point in the lifecycle of any design tool where they start talking about it -- even if they quietly disagree with it in principle. My impression is that it normally happens when they're trying to acquire customers who (unfortunately) practice such dysfunctional team dynamics.
As a developer who designs, I've always found myself jumping between code and visual design tools; but rarely based on the current stage of the project and more often based on what kind of thinking I want to do. If I want to engage with the constraints I more often do it in code, if I want to explore tangents, I open up the design tool.
To me, one of the dirtiest words in dev <> designer interaction is "handoff". There's always a point in the lifecycle of any design tool where they start talking about it -- even if they quietly disagree with it in principle. My impression is that it normally happens when they're trying to acquire customers who (unfortunately) practice such dysfunctional team dynamics.
As a developer who designs, I've always found myself jumping between code and visual design tools; but rarely based on the current stage of the project and more often based on what kind of thinking I want to do. If I want to engage with the constraints I more often do it in code, if I want to explore tangents, I open up the design tool.
Ive really warmed up to the lowercase-a "agile" way of working in this way. Earlier in my career I just wanted design to have everything fleshed out and ready to go, that was their "job". I’ve now seen that fail multiple times.
It can be hard to communicate it to coworkers sometimes, but a lot of this would be much smoother if we all understood our jobs as making the product we ship. The design isn’t a product and nor is the repo. The designer might hold the pencil, and I might hold the brush but we’re both working on the same canvas.
It can be hard to communicate it to coworkers sometimes, but a lot of this would be much smoother if we all understood our jobs as making the product we ship. The design isn’t a product and nor is the repo. The designer might hold the pencil, and I might hold the brush but we’re both working on the same canvas.
I agree with the general sentiment—over-optimizing for design can both be a poor use of time and lead to less than ideal solutions.
I don't really agree that Figma is forcing designers into a box. The author feels like there's an ideal workflow—a quick sketch that gets translated into code. There's no ideal workflow. It completely depends on the delivery team.
That sketch to code flow probably works well with a small team that is used to working closely together. I've been working with most of the engineers on one of my delivery teams for five years. Frequently, I don't need designs at all! I can just write a JIRA card and because we are so used to working together many times they can pick up on the desired result.
Unfortunately, when the product org gets larger you get a lot of designers and engineers and delivery teams that don't spend a lot of time together. You need the clearest representation of those components—often documented down to the exact props that should be implemented. That is exactly how many enterprise software organizations are using Figma. Design and code components have props (for visual changes) that mirror one another.
Overall, Figma is geared pretty well to how many product orgs are delivering software.
I don't really agree that Figma is forcing designers into a box. The author feels like there's an ideal workflow—a quick sketch that gets translated into code. There's no ideal workflow. It completely depends on the delivery team.
That sketch to code flow probably works well with a small team that is used to working closely together. I've been working with most of the engineers on one of my delivery teams for five years. Frequently, I don't need designs at all! I can just write a JIRA card and because we are so used to working together many times they can pick up on the desired result.
Unfortunately, when the product org gets larger you get a lot of designers and engineers and delivery teams that don't spend a lot of time together. You need the clearest representation of those components—often documented down to the exact props that should be implemented. That is exactly how many enterprise software organizations are using Figma. Design and code components have props (for visual changes) that mirror one another.
Overall, Figma is geared pretty well to how many product orgs are delivering software.
> 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.
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.
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.
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.
> To me it’s categorically right: Auto Layout specifically is intended to restrict the possible layout options.
Except that you do not need to use Auto Layout if you don't want to mimic the flow of objects inside a flexbox container. You can just use a regular frame, and position things freely within it. Or, you can use an Auto Layout, but then absolutely position arbitrary elements inside that Auto Layout frame if you want. Auto Layout does not restrict a designer's layout options, it only adds to them.
Except that you do not need to use Auto Layout if you don't want to mimic the flow of objects inside a flexbox container. You can just use a regular frame, and position things freely within it. Or, you can use an Auto Layout, but then absolutely position arbitrary elements inside that Auto Layout frame if you want. Auto Layout does not restrict a designer's layout options, it only adds to them.
> 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.
I have seen nontechnical product managers share this confusion to the strong detriment of projects.
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.
"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.
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 would hope. Building flying air castles in Figma is not really a work that requires high qualification, and reality catches up with those fantasies, when the web dev is told to implement them.
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.
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.
Generalising the point the author is making: how do tools and programming languages shape/influence our thinking. I think this something we all should be asking ourselves.
It’s important to remember that certain concepts simply don’t occur to us as programmers because the language(s) we use.
For example how many JavaScript programmers know what an Erlang supervisor pattern is. How can they if JavaScript doesn’t support it. Perhaps the problem I’m facing in JS would be best solved using a supervisor but since it isn’t available, I don’t use it.
Even the language we speak influences our thinking, so do the tools we use and perhaps we should be aware of that.
It’s important to remember that certain concepts simply don’t occur to us as programmers because the language(s) we use.
For example how many JavaScript programmers know what an Erlang supervisor pattern is. How can they if JavaScript doesn’t support it. Perhaps the problem I’m facing in JS would be best solved using a supervisor but since it isn’t available, I don’t use it.
Even the language we speak influences our thinking, so do the tools we use and perhaps we should be aware of that.
> For example how many JavaScript programmers know what an Erlang supervisor pattern is. How can they if JavaScript doesn’t support it.
I've been running into the opposite issue. we built a project in liveview and the state management is not quite how I'd like it. pretty much everything is a callback to handle_info on a single object where you set the value to socket.assigns but no canonical way of organizing it. The pieces are all there to do some kind of stream based pipeline with an async reducer but no one has done it yet.
JS devs of course already know redux so this is a solved pattern in the js world
I've been running into the opposite issue. we built a project in liveview and the state management is not quite how I'd like it. pretty much everything is a callback to handle_info on a single object where you set the value to socket.assigns but no canonical way of organizing it. The pieces are all there to do some kind of stream based pipeline with an async reducer but no one has done it yet.
JS devs of course already know redux so this is a solved pattern in the js world
sounds like a gen_redux is needed.
hm ... why not actually? What would go into a gen_redux ... gen_event and gen_statem and some coordinated message passing!
hm ... why not actually? What would go into a gen_redux ... gen_event and gen_statem and some coordinated message passing!
Similar to software developers, there's a difference between meeting a user need with with established patterns and exploring novel ones.
The vast majority of consumer and enterprise products ought to be done with established design patterns. Figma is fine for this.
Whereas exploratory design is about coming up with novel patterns. Most of this work ends up being interesting but not particularly practical, and even when someone comes up with something great it's often not yet clear how and where it should be applied. In my experience only a few companies actually pull this off and the rest would be better off following existing conventions. Also in my experience, people who do exploratory design have a wider skillset and use a much broader and more flexible set of tools like pen and paper, physical prototypes, 3d modeling, computer graphics, video production, software development, etc.
The challenge has been that many designers are hired for the former but would prefer to do the latter.
The vast majority of consumer and enterprise products ought to be done with established design patterns. Figma is fine for this.
Whereas exploratory design is about coming up with novel patterns. Most of this work ends up being interesting but not particularly practical, and even when someone comes up with something great it's often not yet clear how and where it should be applied. In my experience only a few companies actually pull this off and the rest would be better off following existing conventions. Also in my experience, people who do exploratory design have a wider skillset and use a much broader and more flexible set of tools like pen and paper, physical prototypes, 3d modeling, computer graphics, video production, software development, etc.
The challenge has been that many designers are hired for the former but would prefer to do the latter.
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: https://youtu.be/Yo7rL0pvHTk?t=147
Our goal is to enable both, not push designers towards one or the other. The author notes:
> You can’t drag things around freely or try odd combinations of layouts. You can’t simply paste something into a frame without it snapping to the bottom of the stack.
What the author is seeing isn't Figma restricting your ability to design, it's other designers adopting it as part of their process. I'd encourage the author to dive into the why of that. What we've found is that often times these structured design approaches can accelerate even freeform design - rarely do you want a menu that doesn't have equal gaps between similar items, so quickly adding that logic can let you move faster. More importantly though, quickly moving past those repetitive parts of the design can let you more quickly focus on the more creative parts.
All that said, these structured approaches can be overbaked, which is what the author might be seeing. Knowing when not to use features such as autolayout can be just as important as knowing how to use them. The most important thing though is you can always detach from them. One of the top requests we've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.
Happy to answer any questions about any of this though - this is my bread and butter.
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: https://youtu.be/Yo7rL0pvHTk?t=147
Our goal is to enable both, not push designers towards one or the other. The author notes:
> You can’t drag things around freely or try odd combinations of layouts. You can’t simply paste something into a frame without it snapping to the bottom of the stack.
What the author is seeing isn't Figma restricting your ability to design, it's other designers adopting it as part of their process. I'd encourage the author to dive into the why of that. What we've found is that often times these structured design approaches can accelerate even freeform design - rarely do you want a menu that doesn't have equal gaps between similar items, so quickly adding that logic can let you move faster. More importantly though, quickly moving past those repetitive parts of the design can let you more quickly focus on the more creative parts.
All that said, these structured approaches can be overbaked, which is what the author might be seeing. Knowing when not to use features such as autolayout can be just as important as knowing how to use them. The most important thing though is you can always detach from them. One of the top requests we've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.
Happy to answer any questions about any of this though - this is my bread and butter.
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 intentional nor have the designers realised the impact of them, especially when it comes to responsive design.
FWIW I think the next big improvement (from eng side) would be some sort of (simplified?) git style version control for figma. For big projects with many people collaborating this would be hugely helpful, but would actually be hugely useful even with small teams.
We often spend so much time as engs implementing designs to find out they were one revision behind or hadn't actually been signed off, especially working remotely.
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 intentional nor have the designers realised the impact of them, especially when it comes to responsive design.
FWIW I think the next big improvement (from eng side) would be some sort of (simplified?) git style version control for figma. For big projects with many people collaborating this would be hugely helpful, but would actually be hugely useful even with small teams.
We often spend so much time as engs implementing designs to find out they were one revision behind or hadn't actually been signed off, especially working remotely.
> 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 number, and you can't have multiple versions in use at once (ie you can't publish both a 2.0 and a 3.0 version of a library). We are looking at improving this, but as I think you caught on, there's a balance between making it equivalent to eng flows while also simple enough for more casual designers.
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 number, and you can't have multiple versions in use at once (ie you can't publish both a 2.0 and a 3.0 version of a library). We are looking at improving this, but as I think you caught on, there's a balance between making it equivalent to eng flows while also simple enough for more casual designers.
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!
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!
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.
>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've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.
Its not always useful to be able to let people do this though, if you're implementing a feature in applications design side, and it needs to best represent the constraints of the team who will need to implement it on the engineering side, shared constraints would be amazing so they don't diverge too much, and you can get actual consistency.
What you're basically saying is: fuck consistency, this tool doesn't care about an organizations need to enforce that on a tool level
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've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.
Its not always useful to be able to let people do this though, if you're implementing a feature in applications design side, and it needs to best represent the constraints of the team who will need to implement it on the engineering side, shared constraints would be amazing so they don't diverge too much, and you can get actual consistency.
What you're basically saying is: fuck consistency, this tool doesn't care about an organizations need to enforce that on a tool level
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.
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.
> 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 address this however:
> Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one
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.
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 address this however:
> Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one
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.
>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
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
Wow. Trying to work with a design for hire house lately, who insists that Figma is THE TOOL we must be ALL IN on. This paragraph
>> Another feature is Dev Mode, which, in theory, is the missing bridge between the design specification and the technical implementation. However, it enforces a mindset where designers polish designs far away from the technology they are designing for, and where enormous amounts of time are spent on building complex prototypes, only for them to be discarded and rebuilt in code...
really strikes home.
>> Another feature is Dev Mode, which, in theory, is the missing bridge between the design specification and the technical implementation. However, it enforces a mindset where designers polish designs far away from the technology they are designing for, and where enormous amounts of time are spent on building complex prototypes, only for them to be discarded and rebuilt in code...
really strikes home.
The author wishes for a specific workflow that is neither determined nor prevented by Figma. Our tools shape us, yes, but it’s the organization and leadership that actually has the power to create the workflow the author wants, not the tool.
There’s no tool that designers can use that will force organizations to adopt this preferred workflow.
The tools shape us, undeniably, but the agency lies with us. Blaming the tool misses the true story of who has the power to make the world you want.
And as a designer who has to contend with a design system and building consistent UI … this vision of sketch→code→ iterate is beautiful but does not work at scale. Is every feature meant to be a greenfield new idea maximizing my creativity? No. That’s not the job. The job is to create consistent elegant interfaces, and reusing components and tokens and utilizing auto layout is absolutely critical to ensure this. (Okay, I did it before Figma but it took 5x as long and was very difficult to mantain!)
There’s no tool that designers can use that will force organizations to adopt this preferred workflow.
The tools shape us, undeniably, but the agency lies with us. Blaming the tool misses the true story of who has the power to make the world you want.
And as a designer who has to contend with a design system and building consistent UI … this vision of sketch→code→ iterate is beautiful but does not work at scale. Is every feature meant to be a greenfield new idea maximizing my creativity? No. That’s not the job. The job is to create consistent elegant interfaces, and reusing components and tokens and utilizing auto layout is absolutely critical to ensure this. (Okay, I did it before Figma but it took 5x as long and was very difficult to mantain!)
I think what the author is saying is that we’re losing the human touch when doing our initial design work. I’ve felt the same way the past years working in Figma and seeing new features being introduced. It’s a pitty the industry is slowly merging roles together to the point we’re losing the personality in design.
Nothing forces you into using Auto Layout. If you want to drag frames around during ideation, the tool supports that. This is a non-issue.
The "problem" is not figma. It is design in general. Everybody are coping each other which makes sense: You cannot copyright a design and also copying is much easier - and looks better - than designing from scratch.
However while designers will definitely think this as a "problem" which would kill creativity, I as an engineer think that it is the path that would happen later if not now. You can't really blame companies if they want to copy other successful designs - it works.
However while designers will definitely think this as a "problem" which would kill creativity, I as an engineer think that it is the path that would happen later if not now. You can't really blame companies if they want to copy other successful designs - it works.
Coping or copying?
Translating Figmas from designers who don't understand web design is always the root problem, not the tools. They should be concepts of a design, but are often treated as what the final website should look and function like, even though they always overly value static aesthetic design over the chaotic nature of browser sizes, accessibility, variable font sizes, etc.
Which is why quality teams will have designers who have actually made websites before, outside a design or UX tool.
Which is why quality teams will have designers who have actually made websites before, outside a design or UX tool.
Tangential: I have similar thoughts about Jira. The ticket-fication of organizational goals. At least it would be useful to pen any negative repercussions of this
I know it’s trite to just say “you aren’t holding it right!” when it comes to JIRA, but I do think there’s a sensible tool underneath layers of self-inflicted pain. (Self = Atlassian and its users)
User stories, when they’re actually a real problem a real user would need solved, are fine. If you start there, and figuring out how to solve that problem is open to anyone on the team, and you keep the complexity to a minimum (aka, just todo/inprogress/done statuses, and you only try to solve the problem in the story) it’s totally cromulent…
…for start ups who need to ship yesterday and have money to burn.
So IMO not like, the best way to do work, but to do something as fast as possible with people motivated by the problems you’re solving, I like it.
User stories, when they’re actually a real problem a real user would need solved, are fine. If you start there, and figuring out how to solve that problem is open to anyone on the team, and you keep the complexity to a minimum (aka, just todo/inprogress/done statuses, and you only try to solve the problem in the story) it’s totally cromulent…
…for start ups who need to ship yesterday and have money to burn.
So IMO not like, the best way to do work, but to do something as fast as possible with people motivated by the problems you’re solving, I like it.
> User stories, when they’re actually a real problem a real user would need solved, are fine.
Some times. Other times they are detrimental, you need an algebra of composable operations up-front and any abstraction you put on the process of designing those will make people design a broken UX.
User stories are useful mostly for "flux-based" applications where the user has little freedom.
Some times. Other times they are detrimental, you need an algebra of composable operations up-front and any abstraction you put on the process of designing those will make people design a broken UX.
User stories are useful mostly for "flux-based" applications where the user has little freedom.
> User stories are useful mostly for "flux-based" applications where the user has little freedom.
I'd say basically only useful for those sorts of applications! If you're going by user stories, there should only really be 1 way of solving any 1 issue, and users should get rail-roaded into it. There's always a solution to problems you've closed user stories for, but that's it. Anything outside those is unconsidered and might not even have a "hackable" solution since you're building everything up organically rather than as a designed system.
Great for start ups (saved time and money building the impactful flows, your product only needs to do a few things) but awful for enterprises (users have no freedom to warp your product to their needs, your product needs some predictable structure/rules they can build on... those composable operations you're mentioning.)
I'd say basically only useful for those sorts of applications! If you're going by user stories, there should only really be 1 way of solving any 1 issue, and users should get rail-roaded into it. There's always a solution to problems you've closed user stories for, but that's it. Anything outside those is unconsidered and might not even have a "hackable" solution since you're building everything up organically rather than as a designed system.
Great for start ups (saved time and money building the impactful flows, your product only needs to do a few things) but awful for enterprises (users have no freedom to warp your product to their needs, your product needs some predictable structure/rules they can build on... those composable operations you're mentioning.)
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.
As 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.
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.
It sounds to me like what the effect that the author dislikes is actually more often than not a good thing.
Of course non-conventional designs have their time and place as well, but I'm not worried about designers being unable to pursue those just because Figma nudges them in the other direction.
Of course non-conventional designs have their time and place as well, but I'm not worried about designers being unable to pursue those just because Figma nudges them in the other direction.
Isn't that just a guardrail or sensible default?
As someone who's worked in this field and seen it evolve for 20 years, this article really captures how I feel too about how tools shape your mindset and what you create.
The tool you have at hand has a huge impact on how you think. "When all you have is a hammer, everything looks like a nail" and all that.
Nothing shuts down a feeling of exploration and creativity more than loading up a Figma file made up of components assembled with auto-layout. Sometimes you just want to play, rules be damned. That's when the magic happens.
This is not a dig at Figma. It just happens to be that Figma has become huge, and so the opinion its UI has about what you should be designing has a huge impact on the industry.
The tool you have at hand has a huge impact on how you think. "When all you have is a hammer, everything looks like a nail" and all that.
Nothing shuts down a feeling of exploration and creativity more than loading up a Figma file made up of components assembled with auto-layout. Sometimes you just want to play, rules be damned. That's when the magic happens.
This is not a dig at Figma. It just happens to be that Figma has become huge, and so the opinion its UI has about what you should be designing has a huge impact on the industry.
Yes, we should be cautious about tools shaping the way we think. But I’d argue that blaming Figma for narrowing the design process is like blaming Photoshop for bad photo editing. It's not the tool, it's how we use it.
Thanks to this threads I feel less alone about how uncomfortable using figma is.
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“.
Curious why previous discussions are [dead]?
https://news.ycombinator.com/from?site=designsystems.interna...
https://news.ycombinator.com/from?site=designsystems.interna...
I deeply, deeply despise the Figma-style design language that everything uses now, where there's barely any indication of what's clickable vs. what isn't and every screen is an endlessly-scrolling set of tiles and pills.
No borders, no button depth, no hyperlinks, huge swaths of blank monochrome space, menus distributed randomly, and my least favorite software design element of all time--scroll bars that aren't visible unless you're actively scrolling, but there actually are additional options on the list hidden in the borderless flat color below or above the list, so it looks like there's a static menu when in fact it's a scroll list.
I realize that I do not represent the most common user and that most people prefer as few clicked interactions with their software as possible (and also as little reading or learning as is possible), but I have vivid memories of when I could control computers and applications like I was at the command deck of a vehicle, and I greatly miss those days.
No borders, no button depth, no hyperlinks, huge swaths of blank monochrome space, menus distributed randomly, and my least favorite software design element of all time--scroll bars that aren't visible unless you're actively scrolling, but there actually are additional options on the list hidden in the borderless flat color below or above the list, so it looks like there's a static menu when in fact it's a scroll list.
I realize that I do not represent the most common user and that most people prefer as few clicked interactions with their software as possible (and also as little reading or learning as is possible), but I have vivid memories of when I could control computers and applications like I was at the command deck of a vehicle, and I greatly miss those days.
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.
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.
Microsoft flat style too.
Lack of affordances, to use UXspeak. This is terrible, user-hostile design.
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?
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?
It's not like Figma forces to use those features, right? And also, hot take, "limits the possible expressions" is a good thing for application design. Application is not art, first and foremost it must solve user's use case, be accessible, discoverable, ergonomic and practical to implement. Aesthetics must serve and complement those purposes, not be the focus of the design
It's kind of like observations from psycholinguistics: language shapes culture and ideas, and vice-versa. Perhaps the tool makers should listen even more closely to designers to maintain the essential expression of creativity, and this might mean physible assistive devices in the real world.
I never really got the almost code, but still not code appeal of figma. Like the author, I get the design into real code asap. I'll even use a sketch CSS library just so the client can interact and give real feedback. Clicking through an interactive but fake UX is just not real enough for me. Too much bike shedding.
As far as web application design, there are only so many useful idioms. Iterating over actual working interfaces I find the most rapid and satisfying way to design. I built my last app this way. Albeit I'm in ultimate control of the design and build. Experience may differ if these are separate responsibilities.
As far as web application design, there are only so many useful idioms. Iterating over actual working interfaces I find the most rapid and satisfying way to design. I built my last app this way. Albeit I'm in ultimate control of the design and build. Experience may differ if these are separate responsibilities.
Engineers here will disagree of course but the job of the designer is to dream and your job is to build it
That's true in the world without budget constraints. Sometimes minimal changes in the design result in drastic changes to the implementation effort. Sure, I can build anything, but the client may not be happy if I spend a couple of months rewriting entire front-end just to accommodate designer's dream.
> 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.)
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 label, was to solve the right problem for the right people.
I feel like software creation in this decade is increasingly about the creation of beauracracies. Different roles. Different processes. More people than ever before. Everyone vying that their contribution is essential, and that others need to stay in their lanes. I miss the old days honestly. I told myself I would not be like this as I aged. I'm struggling to execute on that hope. :|
I often call them the D's of organizations. Doers, Deciders, Discussers. We seem to have less and less respect for the plight of the Doer, and more and more desire to legitimize the others in disproportionate amounts. Pournelle's Law I guess.
I feel like software creation in this decade is increasingly about the creation of beauracracies. Different roles. Different processes. More people than ever before. Everyone vying that their contribution is essential, and that others need to stay in their lanes. I miss the old days honestly. I told myself I would not be like this as I aged. I'm struggling to execute on that hope. :|
I often call them the D's of organizations. Doers, Deciders, Discussers. We seem to have less and less respect for the plight of the Doer, and more and more desire to legitimize the others in disproportionate amounts. Pournelle's Law I guess.
> 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.
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.
But doing away with that crap was what drew lots of old skool coders in in the first place. Myself included. Now I need 10x the resources to do anything compared to my Delphi 6 and PHP 3 days. It sucks.
It should be as you say, but is not happening. I've found many artists using Divi and Elementor producing shit with premade crap blocks.
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
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
Just as the best architects were often engineers, the same is true of design.
No this is almost universally untrue. But they do have a solid grasp of it
Designers must also make useful things rather than just pretty things or they are just artists rather than architects.
You've perfectly captured my frustration with Figma, thank you.
[deleted]
this is why using atlassians old tired products will also leak into your apps ux
Meh. Figma is for UI designs, not "Design", in the sense of what Creative Review mag etc
Figma balls
As someone who has to actually build the crazy parallax-3d-not-a-grid layout the designer may have spend an hour on, I'm glad.
Maybe free flowing designs shouldn't take place in figma, it should only be for the final output. Even then the majority of apps being built everyday are simple crud apps and shouldn't be overdesigned. They are built for people to do their jobs.
Maybe free flowing designs shouldn't take place in figma, it should only be for the final output. Even then the majority of apps being built everyday are simple crud apps and shouldn't be overdesigned. They are built for people to do their jobs.
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 tab is unresponsive”. You can barely view a long variable list, forget editing one with multiple modes. And, I hope your variable names aren’t too long, because you’re not going to be able to see them in most parts of the UI.
The problem with Figma isn’t that it’s too engineer-y for designers, the problem is that it’s too designer-y for engineers. I spent a month implementing my design system in Figma before giving up and just doing it in code. With Figma you run into all of the downsides of building the design system in code (deeply nested items breaking when you move/change something) but you get none of the advantages.
Figma is a mound of half-baked (vaguely web-like) ideas, poorly implemented. So many times I’ve had things just stop working with no way to figure out why. 99% of the time it’s just a bug and you have to reload the app.
If there’s something better than Figma out there, please, let me know. For now I’m sketching in Figma and building my design system with extensions to Style Dictionary.