[HN Gopher] When Figma starts designing us
___________________________________________________________________
When Figma starts designing us
Author : bravomartin
Score : 199 points
Date : 2025-07-06 10:38 UTC (1 days ago)
(HTM) web link (designsystems.international)
(TXT) w3m dump (designsystems.international)
| adithyassekhar wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| An innovative custom designer can use other tools or do manual
| animations / layout if they require.
| _bent wrote:
| 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
| wx196 wrote:
| Figma actually now has grids: https://help.figma.com/hc/en-
| us/articles/31289469907863-Use-...
| _bent wrote:
| those are layout grids and not grid layout (huge
| difference!)
| wx196 wrote:
| You're right, I used a wrong link, fixed now. So Figma
| has both.
| no_wizard wrote:
| now to get designers to actually use these things.
|
| Figma has a bunch of good tooling, but getting designers to
| use it, and use it consistently, is the real problem.
|
| Designers exist in a realm seemingly, where outside
| pressure can't really be put on it from an organizational
| level to get them to uniformly adopt a set of standards
| they will always adhere to. Every company I have worked at,
| big, medium, small, seems to have this problem
| Oarch wrote:
| It's absolutely trivial to make any element ignore the auto-
| layout grid.
| yreg wrote:
| 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 wrote:
| Isn't that just a guardrail or sensible default?
| sumeruchat wrote:
| Engineers here will disagree of course but the job of the
| designer is to dream and your job is to build it
| robertlagrant wrote:
| Just as the best architects were often engineers, the same is
| true of design.
| tsunamifury wrote:
| No this is almost universally untrue. But they do have a
| solid grasp of it
| asoneth wrote:
| > 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 wrote:
| 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.
| n3storm wrote:
| It should be as you say, but is not happening. I've found
| many artists using Divi and Elementor producing shit with
| premade crap blocks.
| jacekm wrote:
| That's true in the world without budget constraints. Sometimes
| minimal changes in the design result in drastic changes to the
| implementation effort. Sure, I can build anything, but the
| client may not be happy if I spend a couple of months rewriting
| entire front-end just to accommodate designer's dream.
| asoneth wrote:
| 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 wrote:
| 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 wrote:
| 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.
| PaulHoule wrote:
| 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.
| bornfreddy wrote:
| This! It is bad enough that most designers think they are UX
| experts too (few of them are), but trying to micromanage devs
| so that every screen would be "pixel perfect" really takes
| the cake. Especially when the provided designs (that should
| be followed religiously) are missing core functionality and
| the whole flows. Just give me the guidelines please, and
| please please be consistent with them!
|
| Well, I'm sure they have their own set of gripes about the
| developers too. ;-)
| sfifs wrote:
| 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.
| spookie wrote:
| Yeah...
|
| Just do pictures on the design phase and then code.
| miiiiiike wrote:
| There's a lot that goes into creating the pictures.
| Consistent spacing, colors that change depending on platform,
| breakpoints, containers, and on and on and on.
|
| There's no reason that a tool can't model a design system and
| make producing consistent designs that use it trivial.
|
| I think the problem with Figma is that it tries to appeal to
| visual designers, UX designers, and programmers. Good for
| business, bad for users.
| danielvaughn wrote:
| 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.
| desireco42 wrote:
| Yeah we need that... and more HTML it is, the better.
| ThePatientTiger wrote:
| That would be awesome, Looking forward to it.
| danielvaughn wrote:
| Thanks, I can't wait to showcase it on here. It's
| frustrating because I can only work on it on nights and
| weekends, and my 15 month old daughter doesn't make that
| any easier.
|
| I'm incredibly pumped for it, though. It's almost entirely
| keyboard driven, kinda like Vim. I'm building this rich set
| of mnemonic commands to build/design UI components. It's
| like Vim + Storybook + WebFlow.
| screye wrote:
| Isn't this the problem with all no-code / low-code platforms ?
|
| Code is merely the leanest human-readable representation for
| loss-less specification of requirements.
|
| We're seeing this same pattern with 'K8s YAMLs' and 'prompt
| engineering'. There is an entire industry that's re-inventing
| new DSLs which inevitably converge to a scripting language as
| requirements get more complex.
|
| Instead of reinventing the abstraction, I'd like to see no-code
| UX patterns that losslessly map onto the underlying
| abstraction. That way you can use the UX pattern until it gets
| too tedious, and occasionally dip in-and-out of the code-view
| in a non-jarring manner.
|
| Graph UI for manipulating git trees (gitgraph) is a great
| example. Orchestration UI views (Airflow / Langraph) are
| another example that's getting there. At a higher level of
| abstraction, Notion (CRDT UIs) do a good job of representing
| collaboration-locks using blocks. At the highest view, I'm a
| big fan of how Gather-town represents remote collaboration.
|
| I'd like to see more of this.
| PaulHoule wrote:
| From my viewpoint the benefit of low-code is that the average
| business application is a matter of people filling out forms.
| If you want to radically lower development time you have to
| solve _all_ the problems
|
| https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p.
| ..
|
| For instance, a 2025 no code platform is likely to have "one
| click" deployment of a cloud application. That's great if you
| can accept that but if you require "on prem" this is either
| disqualifying or requires you to build an environment on prem
| that can host whatever it is they generate, which could be
| more trouble than building an application the old fashioned
| way in an environment you already know how to run.
|
| A conventional analysis is that you should be able to
| generate a CRUD application out of a schema: you need a
| little bit more than something that looks at a SQL schema and
| creates a form to INSERT, UPDATE or DELETE, but that's a
| start.
|
| One problem is that people write schemas that suck despite
| there being a body of "commonsense knowledge" about how to
| the world works. I had a year when I fixed a tremendous
| number of broken applications and one insight I got out of
| that was that whether it was a student who went from being an
| applicant to being enrolled to being an alumni or a pallet
| that would live in a logistics network and then enter a
| "reverse logistics" network and be inspected and possibly
| repaired to be returned to the logistics network the same
| data model of an object going through a number of states with
| state transitions was general and much better than the 15+
| date columns that were added haphazardly to those columns.
|
| Another example that kept turning up was that the ticket "1
| phone number for a customer is not enough, support 2 phone
| numbers" is inevitably followed by "2 phone numbers is not
| enough, support 3 phone numbers" -- it saves time to work the
| proof by induction up front and just support N phone numbers
| up front. But talk that way and people think you're a lunatic
| like Doug Lenat.
|
| Deployment, code generation from schemas, and schema
| generation from meta-schemas are part of the solution but if
| you can't solve 100% now getting that last bit is ultra-hard
| mode because all the essential complexity hidden by the
| framework is suddenly in your face.
| noduerme wrote:
| >> an object going through a number of states with state
| transitions was general and much better than the 15+ date
| columns
|
| It amazes me that anyone would write a schema with a dozen
| date columns, but I've seen such things. Once you're
| dealing with a large database of something like that, it's
| tempting to just add one more column rather than pitch why
| you should refactor the whole thing.
|
| I try to keep my schemas relational as possible. Actions
| and immutable records should obviously be stored in
| separate tables from the objects they reference. However,
| this _does_ make the UX form design / CRUD process less
| amenable to simple solutions where forms are just generated
| right out of a schema.
|
| Your phone number example highlights this. In general of
| course you want to store contacts in a separate table from
| customers. But that means you're probably going to need a
| separate contacts sub-form within your customer form,
| rather than just inline phone fields. Then form will need
| to be required or inlined for any new customer before the
| main customer form can be saved. Stuff like that.
|
| Over the last 15 years or so I've built and refined my own
| form generator, really a DSL for designing forms that fit
| this type of thing. In its more basic use cases, each form
| lives as a row in a database, with each form_item linked to
| it in a separate table. The form runs a pre-fab query that
| expects N inputs that it binds to :variables (usually in
| WHERE or HAVING clauses) and then renders a pre-populated
| visual form with various input types like dropdowns,
| checkboxes, calendars, etc (based on those form_items,
| which can all be styled, required/not required, required
| based on other answers, etc). Each form_item has its own
| standard validation or custom validation function on both
| the client and server side. The form knows which table it
| wants to write to and which bound variable is the id field
| it's going to target for update. Sending it a blank id
| field renders the form with nothing populated and then does
| an insert instead of an update when it's submitted. It's
| very slim, about 500 LOC of Typescript and 700 LOC of PHP,
| including most standard kinds of validations on both ends.
| I've always toyed with the idea of releasing it it for
| people to use, but here's the rub: If you want to do
| anything involving _writing_ to more than one table, you
| need to write a custom final function for those additional
| insert /updates.
|
| So, it's a lovely system, but someone coming to it naively
| would run the risk of designing schemas that were not
| expressive enough, to try to keep the CRUD system happy.
| And I think this is just an inevitable problem with all
| low-code solutions: They don't handle multi-dimensional
| data the way you want a clean schema to handle it. (And
| neither do users).
| marcosdumay wrote:
| > Code is merely the leanest human-readable representation
| for loss-less specification of requirements.
|
| Hum... That's assuming you have a perfect development stack
| that hides all non-essential complexity.
|
| And well, I have news for you, that's a low-code platform. A
| generic stack that hides every problem but solves every
| requirement just can't exist.
| SirHumphrey wrote:
| While code may no be the leanest human-readable
| representation, scripting languages are a quite deep local
| minimum. There is a difference between hiding complexity
| and blocking you off from complexity. Scripting languages
| work because when you encounter a problem your library /
| framework can't fix, there is at least a basic procedural
| Turing complete language to fall back on.
| NewsaHackO wrote:
| 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 wrote:
| 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.
| raincole wrote:
| > 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.
| whywhywhywhy wrote:
| Fireworks also existed the whole time which had a lot of
| Figma's features but bizarrely was completely ignored by 95%
| of designers.
| cosmic_cheese wrote:
| 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.
| miiiiiike wrote:
| I had my UX designer girlfriend read "CSS: The Definitive
| Guide" and it changed the way she looked at her job. She
| taught me Figma and it changed the way I look at my job, and
| hers.
|
| Learn as much as you can. Specialization is for insects.
| cosmic_cheese wrote:
| I advocate for learning as much as possible as well. It
| comes naturally with being self-taught. That said I think
| it's also worth zooming out and giving things a look
| through a critical eye to ensure that the things we're
| learning are necessary and worthwhile.
|
| There are still a number of "old school" UI designers out
| there who've resisted trends and have staunchly stuck to a
| more traditional workflow, where they start out with a
| rough mockup made in e.g. Photoshop and then iterate the
| design alongside an engineer. It would be interesting to be
| in the room amidst a discussion between one of these
| traditionalists and a "new age" Figma-type UI designer.
| luckylion wrote:
| What did you learn about Figma that changed how you think
| about your work?
| cryptozeus wrote:
| I have totally opposite experience working on large ds at uber
| The5thElephant wrote:
| Exactly this. Thank you.
|
| We need a Blender-like design tool specifically for product
| design. Using HTML/CSS for rendering so it covers most web
| needs and that usually more than encompasses native app-layout
| emulation. Open source, technical, and not expected to be
| picked up in a day or fully understood top-to-bottom by
| everyone.
|
| The reason Figma is putting us into a design box is because it
| doesn't have all the CSS features that actually let you create
| incredible experiences.
| no_wizard wrote:
| as much as folks hate electron, I think if Figma was
| electron, it would at least have the entire chromium web
| engine to work with
| ThePatientTiger wrote:
| "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.
| samsolomon wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pyrale wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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(tm). 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 wrote:
| 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 wrote:
| 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.
| Lalabadie wrote:
| These are complaints about the designer you are working with
| and the deliverables they're choosing to give you, are they
| not?
|
| Figma isn't/shouldn't be the arbiter of what's possible in
| the project, that's a major point of the article.
|
| My role as a designer is to explore options and _then_ narrow
| down to a sensible solution (diamond-shaped process, etc
| etc). My developer colleague is concerned by the second part
| of that process, and I should make sure to provide her with
| consistency and sensible use of exceptions. That doesn't
| change my responsibilities to the exploratory part, and I
| can't exclude it from my consideration when choosing and
| critiquing tools.
| no_wizard wrote:
| >These are complaints about the designer you are working
| with and the deliverables they're choosing to give you, are
| they not?
|
| It is, to some degree, but the tools don't help any related
| party enforce consistency that will translate to the
| broader output of that work, that doesn't help matters very
| much.
|
| In addition, designers themselves by and large don't seem
| to care _enough_ about consistency like this. Engineers
| have design systems (ideally) that they pull from, but I 'm
| still shocked in 2025 there is no good 1-1 communication of
| imposing the constraints of a design system in the designer
| <> engineer workflow.
|
| Not to mention, for every designer I know that does adopt
| features of the tool that make this easier, like auto
| layout, there's a much greater number of designers that
| refuse to use them.
|
| Seemingly, engineers hold themselves to a higher standard
| of consistency than designers do. I've seen this pattern
| too many times and its the only reasonable conclusion I've
| been able to draw. I was even hired to help streamline
| engineering and design work together and share as much as
| possible to get a corporate design system adopted, and I
| always had a hell of alot more resistance and argument with
| the design side of that equation on this.
|
| edit: after seeing someone from Figma comment, I feel its
| unlikely it will ever have any of these types of features,
| which is a shame
| jjcm wrote:
| PM on Design Systems here at Figma.
|
| There's an element of truth to this post, but I think the
| author's conclusions are incorrect.
|
| First is the truth - we are working on things that allow designs
| to be closer to code (allow here is the key word, not enforce).
| We've always seen Figma as being at the center between Freeform
| and Structured design - I talked about it in depth during our
| keynote at Schema 3 years ago: https://youtu.be/Yo7rL0pvHTk?t=147
|
| Our goal is to enable both, not push designers towards one or the
| other. The author notes:
|
| > You can't drag things around freely or try odd combinations of
| layouts. You can't simply paste something into a frame without it
| snapping to the bottom of the stack.
|
| What the author is seeing isn't _Figma_ restricting your ability
| to design, it 's _other designers_ adopting it as part of their
| process. I 'd encourage the author to dive into the why of that.
| What we've found is that often times these structured design
| approaches can accelerate even freeform design - rarely do you
| want a menu that doesn't have equal gaps between similar items,
| so quickly adding that logic can let you move faster. More
| importantly though, quickly moving past those repetitive parts of
| the design can let you more quickly focus on the more creative
| parts.
|
| All that said, these structured approaches can be overbaked,
| which is what the author might be seeing. Knowing when not to use
| features such as autolayout can be just as important as knowing
| how to use them. The most important thing though is you can
| always detach from them. One of the top requests we've had from
| Design Systems authors for a while now is to prevent detaches,
| but it something we've never implemented, mainly because we
| always want a way to allow the designer to fully go back to that
| freeform design mentality. You can always remove an autolayout,
| you can always detach an instance, you can always break a
| variable. They're optional features, not handcuffs that bind you.
| If you want to go a step further, there are plenty of plugins out
| there that _fully_ detach all restrictive elements on a
| selection, making all colors a hex code, all autolayouts removed,
| and everything absolutely positioned so you can just drag things
| around. We don 't provide a native feature to do this (since it's
| a fairly extreme measure that removes a lot of helpful metadata),
| but we also don't prevent actions like this if people really want
| to go to the creative extremes.
|
| Happy to answer any questions about any of this though - this is
| my bread and butter.
| no_wizard wrote:
| >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
| jjcm wrote:
| > Is there any way you can get a global toggle to change
| that? Because enforce is what is often desired
|
| I agree with your premise, but not with your conclusion. A
| way to block detaches would not bring this closer to code -
| there's no real concept of "detach" in code, but you can
| always simply create a new component. In the same way, we
| want designers to have the capability as well. You do land on
| the correct way to address this however:
|
| > Engineers have tests and linters, there's no allegory to
| that in the design world, and it desperately needs one
|
| Linting on handoff, aka process, is the way to solve this,
| not dogmatic restrictions. You should always provide freeform
| design, otherwise your design language never evolves to
| changing requirements, but doing so should be an explicit
| choice and part of a process. Completely locking that down
| will also lock down creativity. This is what I was talking
| about in the talk I linked above about balance - going too
| far on either end will harm the overall process.
| no_wizard wrote:
| >Linting on handoff, aka process, is the way to solve this,
| not dogmatic restrictions. You should always provide
| freeform design, otherwise your design language never
| evolves to changing requirements, but doing so should be an
| explicit choice and part of a process. Completely locking
| that down will also lock down creativity. This is what I
| was talking about in the talk I linked above about balance
| - going too far on either end will harm the overall process
|
| Process is fine, but enforcing process is what is desired.
| Being able to express constraints globally (IE,
| organizationally) may limit creativity in an absolute
| sense, but within constraints you can have your own kind of
| creativity.
|
| That means not designing features that don't fit within the
| bounds of a layout for example. Not the easiest to 'process
| lint', but the tool would know instantly. Thats what I'm
| talking about. Hand waving that away as a 'process human
| problem' is disingenuous and I'm rather frustrated thats
| the response Figma has to this.
|
| So called "dogmatic restrictions" exist for a reason.
| Though, to say being able to enforce consistency by being
| able to say, only allow auto layout and associated
| features, isn't really 'dogmatic'. Just like linters catch
| features of a language nobody really should use anymore
| (like JavaScript's `with` for example) is the correct way
| to solve this problem. Thats not really dogmatic, its just
| good hygiene.
|
| If Figma doesn't care about any of these real problems,
| than fine, then make yourself plain and say so explicitly,
| otherwise the tool has a huge gap in functionality that
| makes it irritating to actually evolve with.
|
| I imagine this is why Figma has no concept of a staging
| area either, or a proper VCS, nor a review pipeline, which
| are also gaps in functionality that would relieve so many
| issues
| drewbeck wrote:
| I've never worked in an org where this would be necessary but
| I can see the use case. If you only want to give your
| designers building blocks and expect them to use them only,
| then preventing detach makes a lot of sense.
|
| If there's any flexibility in your designers' work, though,
| preventing detach would be very frustrating: to create a new
| thing we'll (designers) often pull from an existing component
| and detach it in order to harvest it for parts. Not being
| able to do that would drive me batty.
| martinald wrote:
| FWIW I think you're mostly on the right track. I have noticed
| the "implementation ability" of designs that have came over
| from designers since figma had autolayout massively improve.
|
| Maybe there is an argument that it is stifling creativity
| (though I'm not entirely convinced of this), but it is saving
| SO MUCH eng time on implementing (or going back and forth) on
| 'non standard' elements that are often not very intentional nor
| have the designers realised the impact of them, especially when
| it comes to responsive design.
|
| FWIW I think the next big improvement (from eng side) would be
| some sort of (simplified?) git style version control for figma.
| For big projects with many people collaborating this would be
| hugely helpful, but would actually be hugely useful even with
| small teams.
|
| We often spend so much time as engs implementing designs to
| find out they were one revision behind or hadn't actually been
| signed off, especially working remotely.
| jjcm wrote:
| > I think the next big improvement (from eng side) would be
| some sort of (simplified?) git style version control for
| figma
|
| FWIW, we do have a simplified version of version control
| already - there's both version history as well as branching &
| merging in Figma. There are some restrictions with it however
| that make it less compatible with the way engineers think
| about versioning - namely you can't tie it to a version
| number, and you can't have multiple versions in use at once
| (ie you can't publish both a 2.0 and a 3.0 version of a
| library). We are looking at improving this, but as I think
| you caught on, there's a balance between making it equivalent
| to eng flows while also simple enough for more casual
| designers.
| martinald wrote:
| Ah this looks great and exactly what I had in mind - but
| only available on organization plans.
|
| Right now I'm generally working with smaller
| teams/contractors for design stuff (I think this is very
| common btw that you have one designer and at most a couple
| of FE engineers actually working on this) - even in larger
| organisations I've collaborated with doing dev
| implementation for them I'm not sure many have upgraded to
| enterprise, but I get a somewhat limited view of Figma from
| the outside.
|
| It would be awesome if you could enable this with a limited
| number of branches or something (even 2 would be a start -
| master/staging vibes) for pro plans. But I do understand
| that you need to push people to a higher tier - but I
| imagine it would really help adoption if I could push back
| to everyone saying please use branches. It's good to know
| though for future this exists!
| drewbeck wrote:
| As a designer, having the ability to lock certain pages
| from editing or component updates would get us really far
| imo. As it stands creating a canonical version requires
| versioning related components or breaking the component
| link to prevent inadvertent changes to the design. This
| could work per-frame as well - if it's 'ready for dev' then
| it is uneditable and doesn't receive component updates.
| valencamacho80 wrote:
| You've perfectly captured my frustration with Figma, thank you.
| ranie93 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| this is why using atlassians old tired products will also leak
| into your apps ux
| drewbeck wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rorylaitila wrote:
| 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 wrote:
| 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.
| n3storm wrote:
| Thanks to this threads I feel less alone about how uncomfortable
| using figma is.
| JoeSugma wrote:
| Figma balls
| deepsun wrote:
| Curious why previous discussions are [dead]?
|
| https://news.ycombinator.com/from?site=designsystems.interna...
___________________________________________________________________
(page generated 2025-07-07 23:00 UTC)