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.
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.
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.
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.
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.
No, here’s the problem: Figma doesn’t go far enough.
If you need a free form design tool to sketch, use one. There are hundreds of them.
I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this 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.
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.
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 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.
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.
> 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.
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.
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.
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.
"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.
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 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.
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...)
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
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.
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.
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.
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.
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.
> 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.
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.
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.
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
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!)
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...
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.
65 comments
[ 13.0 ms ] story [ 107 ms ] threadMaybe 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.
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.
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.
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
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.
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.
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.
Just do pictures on the design phase and then code.
Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.
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.
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.
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.
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.
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.
And it's free and open source.
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
HTML+CSS works very nice for these mock-ups. Tried Figma and Sketch for a small project, never again.
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.
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.
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.
Which is why quality teams will have designers who have actually made websites before, outside a design or UX tool.
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.
Design software nowadays... oh boy
> 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.
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.
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 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!)
>> 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.
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.