10 ms·

When Figma starts designing us

302 points by bravomartin 1y ago

n3storm 1y ago
Thanks to this threads I feel less alone about how uncomfortable using figma is.
adithyassekhar 1y ago
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.
mananaysiempre 1y ago
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.
- nicoburns 1y ago
  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
- d3vmax 1y ago
  An innovative custom designer can use other tools or do manual animations / layout if they require.
- _bent 1y ago
  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 https://www.youtube.com/watch?v=1Pq7VqNrtk4
  - wx196 1y ago
    Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-the-grid-auto-layout-flow https://help.figma.com/hc/en-us/articles/31289469907863-Use-...
    - _bent 1y ago
      those are layout grids and not grid layout (huge difference!)
      - wx196 1y ago
        You're right, I used a wrong link, fixed now. So Figma has both.
- Oarch 1y ago
  It's absolutely trivial to make any element ignore the auto-layout grid.
yreg 1y ago
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.
- esafak 1y ago
  Isn't that just a guardrail or sensible default?
sumeruchat 1y ago
Engineers here will disagree of course but the job of the designer is to dream and your job is to build it
- robertlagrant 1y ago
  Just as the best architects were often engineers, the same is true of design.
  - tsunamifury 1y ago
    No this is almost universally untrue. But they do have a solid grasp of it
- asoneth 1y ago
  > 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.)
  - travisgriggs 1y ago
    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.
asoneth 1y ago
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.
meteyor 1y ago
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.
miiiiiike 1y ago
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.
- NewsaHackO 1y ago
  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?
  - miiiiiike 1y ago
    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.
- PaulHoule 1y ago
  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.
samsolomon 1y ago
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.
quacked 1y ago
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.
- radley 1y ago
  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...)
  - quacked 1y ago
    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.
    - radley 1y ago
      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.
renerick 1y ago
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
Towaway69 1y ago
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.
- cultofmetatron 1y ago
  > 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
  - Towaway69 1y ago
    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!
karohalik 1y ago
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.
zelphirkalt 1y ago
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.
- H1Supreme 1y ago
  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.
  - ricardobeat 1y ago
    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.
dmix 1y ago
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.
bbx 1y ago
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.
- GenerWork 1y ago
  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.
- sevenseacat 1y ago
  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
pyrale 1y ago
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.
- andrewingram 1y ago
  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.
- graypegg 1y ago
  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.
Lalabadie 1y ago
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.
- zdragnar 1y ago
  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.
  - et-al 1y ago
    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.
jjcm 1y ago
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 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.
- no_wizard 1y ago
  >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
valencamacho80 1y ago
You've perfectly captured my frustration with Figma, thank you.
ranie93 1y ago
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
- graypegg 1y ago
  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.
  - marcosdumay 1y ago
    > 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.
    - graypegg 1y ago
      > 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.)
user9999999999 1y ago
this is why using atlassians old tired products will also leak into your apps ux
drewbeck 1y ago
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!)
dmackerman 1y ago
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.
travisgriggs 1y ago
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.
ThePatientTiger 1y ago
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.
- burnt-resistor 1y ago
  Coping or copying?
rorylaitila 1y ago
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.
iamcalledrob 1y ago
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.
JoeSugma 1y ago
Figma balls
deepsun 1y ago
Curious why previous discussions are [dead]? https://news.ycombinator.com/from?site=designsystems.international https://news.ycombinator.com/from?site=designsystems.interna...
deleted 1y ago
[deleted]
karaterobot 1y ago
> 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.
- markbao 1y ago
  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.
  - karaterobot 1y ago
    > 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.
dandano 1y ago
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.
rukuu001 1y ago
Meh. Figma is for UI designs, not "Design", in the sense of what Creative Review mag etc
ripped_britches 1y ago
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?
HellDunkel 1y ago
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“.
Separo 1y ago
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.
burnt-resistor 1y ago
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.

302 points by bravomartin 1y ago

Thanks to this threads I feel less alone about how uncomfortable using figma is.

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.

mananaysiempre 1y ago

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.

nicoburns 1y ago
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
d3vmax 1y ago
An innovative custom designer can use other tools or do manual animations / layout if they require.
_bent 1y ago
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 https://www.youtube.com/watch?v=1Pq7VqNrtk4
- wx196 1y ago
  Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-the-grid-auto-layout-flow https://help.figma.com/hc/en-us/articles/31289469907863-Use-...
  - _bent 1y ago
    those are layout grids and not grid layout (huge difference!)
    - wx196 1y ago
      You're right, I used a wrong link, fixed now. So Figma has both.
Oarch 1y ago
It's absolutely trivial to make any element ignore the auto-layout grid.

yreg 1y ago

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.

esafak 1y ago
Isn't that just a guardrail or sensible default?

sumeruchat 1y ago

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

robertlagrant 1y ago
Just as the best architects were often engineers, the same is true of design.
- tsunamifury 1y ago
  No this is almost universally untrue. But they do have a solid grasp of it
asoneth 1y ago
> 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.)
- travisgriggs 1y ago
  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.

asoneth 1y ago

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.

meteyor 1y ago

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.

miiiiiike 1y ago

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.

NewsaHackO 1y ago
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?
- miiiiiike 1y ago
  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.
PaulHoule 1y ago
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.

samsolomon 1y ago

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.

quacked 1y ago

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.

radley 1y ago
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...)
- quacked 1y ago
  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.
  - radley 1y ago
    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.

renerick 1y ago

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

Towaway69 1y ago

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.

cultofmetatron 1y ago
> 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
- Towaway69 1y ago
  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!

karohalik 1y ago

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.

zelphirkalt 1y ago

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.

H1Supreme 1y ago
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.
- ricardobeat 1y ago
  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.

dmix 1y ago

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.

bbx 1y ago

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.

GenerWork 1y ago
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.
sevenseacat 1y ago
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

pyrale 1y ago

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.

andrewingram 1y ago
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.
graypegg 1y ago
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.

Lalabadie 1y ago

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.

zdragnar 1y ago
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.
- et-al 1y ago
  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.

jjcm 1y ago

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

no_wizard 1y ago
>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

valencamacho80 1y ago

You've perfectly captured my frustration with Figma, thank you.

ranie93 1y ago

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

graypegg 1y ago
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.
- marcosdumay 1y ago
  > 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.
  - graypegg 1y ago
    > 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.)

user9999999999 1y ago

this is why using atlassians old tired products will also leak into your apps ux

drewbeck 1y ago

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!)

dmackerman 1y ago

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.

travisgriggs 1y ago

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.

ThePatientTiger 1y ago

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.

burnt-resistor 1y ago
Coping or copying?

rorylaitila 1y ago

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.

iamcalledrob 1y ago

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.

JoeSugma 1y ago

Figma balls

deepsun 1y ago

Curious why previous discussions are [dead]? https://news.ycombinator.com/from?site=designsystems.international https://news.ycombinator.com/from?site=designsystems.interna...

deleted 1y ago

[deleted]

karaterobot 1y ago

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

markbao 1y ago
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.
- karaterobot 1y ago
  > 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.

dandano 1y ago

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.

rukuu001 1y ago

Meh. Figma is for UI designs, not "Design", in the sense of what Creative Review mag etc

ripped_britches 1y ago

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?

HellDunkel 1y ago

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“.

Separo 1y ago

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.

burnt-resistor 1y ago

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.