[HN Gopher] When Figma starts designing us
___________________________________________________________________
When Figma starts designing us
Author : bravomartin
Score : 280 points
Date : 2025-07-06 10:38 UTC (2 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
| brailsafe wrote:
| To me, things like mobile-first responsive design and grid-
| based graphic design thinking are core components of
| designing for the web, so it's a bit wild to me that Figma,
| with such popularity, is just now getting grids, and as far
| as I'm aware no GUI tool has ever succeeded at building a
| capable visual responsive design tool close to on-par with
| just designing in the browser.
| mananaysiempre wrote:
| This does not seem _that_ surprising to me.
|
| Browsers are by and large black boxes--less because of
| their architecture and more because of the sheer size of
| the code, although Firefox, for example, seems to have
| been moving towards a less open architecture for most of
| its history as well (deCOMtamination, death of XULRunner,
| Quantum, etc.).
|
| What you really want in a parametric web design tool is
| to crack open the layout engine and the CSS cascade and
| inheritance, at the very least. That's a lot of work to
| target a demographic of designers and programmers who by
| now have largely decided to ignore CSS in favour of
| reinventing inline styles badly (Tailwind) and insert
| markup as necessary for the desired visual effect. (Is
| there a tool to do CSS in terms of React/etc. components,
| with proper cascading, custom pseudoclasses and
| pseudoelements and so on? I haven't seen one.)
| 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.
| asoneth wrote:
| > Can someone help me understand when this bifurcation
| happened
|
| The distinction is as old as art and design. If I had to
| pick modern moments that articulated it well I'd go with
| Arts and Crafts followed by Bauhaus.
|
| > solve the right problem for the right people
|
| Solving problems is the core of design and a design can be
| evaluated on the basis of how well it solves a problem.
| Whereas art is free to simply exist. Many works have
| elements of both, but if you hire someone to solve a
| problem and they believe their job is to make art then
| you'll both be disappointed.
|
| I'm unsure what motivated the rest of your post though I
| can feel your frustration. I will say that bureaucracies
| and processes have been around for centuries, they just
| shift language every decade or so. There has also always
| been a tension between the people who Do and the people who
| Decide but both are necessary for a functional
| organization.
| 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.
| BoorishBears wrote:
| The first thing I did was search for the definition of art
| you're working with
|
| What I found looked like a page that 4.1 nano (not even mini)
| would come up with, so I'm not sure where this energy is coming
| from
| 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.
| immibis wrote:
| Don't create every possible picture. Create a
| representative set.
|
| Draw each screen at least once. If you have dark mode, you
| don't have to fully redraw each screen in dark mode, just
| enough to show how dark mode should look. If it has to work
| on desktop, you probably do have a completely different
| desktop version of each screen (from the default mobile) so
| draw that - but don't redraw every detail of a widget
| that's identical to mobile.
|
| Testing every combination should be for the testing stage.
| It's good if you can foresee clashes (like the desktop
| version of this widget looks bad on this page in dark mode)
| in the design stage but it's not really an excuse to
| prolong the design so long that it lasts until you would
| have been finished with testing anyway.
|
| Having a computer generate all the combinations for you in
| the design stage isn't that great unless you can pay
| individual attention to them - there's no point producing
| artefacts that nobody looks at.
| brulard wrote:
| I don't think you got the point. Instead of "pictures" we
| need a design system - defined sizes, paddings, margins,
| grids, font-sizes, colors, breakpoints, variants,
| components, behaviors, transitions, etc. and it should be
| consistent across the app. How many times have I worked
| with a design that didn't respect these consistently from
| page to page...
| 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).
| mattmanser wrote:
| I've made automated form editors, companies I've worked
| for have done it. They had data nesting, with no custom
| functions for handling it. For example I've made a fully
| customisable menu editor where you could add sections,
| sub sections, prices to items, prices to sub items,
| prices for picking 2 out of X items in the menu. All
| sorts of crazy (optional) nesting. All saved in different
| tables. Took me like 2 weeks. I felt very clever at the
| time. Frontend was all in jQuery too!
|
| They all saved to relational databases with multiple
| tables. One form editor (which wasn't mine), allowed you
| to add new columns (this was in the on-prem days and back
| then they avoided future collisions by prefixing the
| custom columns with ex_).
|
| The problems you listed above are solveable. You don't
| need custom functions, you need clever property naming.
| Most ORMs have to solve them too.
|
| So nested data is not actually a problem for lo-code
| solutions, it's a solvable/solved problem.
|
| And I STILL regularly leave that sort of data
| denormalized. I write multiple date columns (e.g.
| created, lastUpdated, etc.). I still write mobile + work
| numbers as columns for plenty of apps.
|
| Why? It's simple YAGNI. For many apps it's quicker and
| easier to denormalize the data and keeps the code much,
| much simpler.
|
| Plenty of apps that I've seen that have been going 15+
| years haven't normalized that data and it's fine.
|
| The problem comes when no-one refactors and keeps adding
| them.
|
| But it's extra work and it's "dangerous" work,
| potentially data destroying if you get it wrong.
|
| You get no thanks, as other devs will moan it's more
| complicated to use, and if you slip up you might get
| fired.
|
| So most devs take the easier and safer option and just
| add a new column.
| btown wrote:
| Change management, designing schemas for being amenable to
| change management, having systems that can migrate data
| with an understanding of what _historical_ context in which
| that data got into the system (was it imported from a
| source with a nuance that was fine before you changed the
| form, but now makes less sense with the updated meaning and
| positioning of the field?)... all of this is what makes
| software hard, whether low-code or high-code!
|
| One of the ironic things, to bring it back to Figma, is
| that giving designers and stakeholders Figma in all its
| glory becomes a justification for having engineers on the
| project, because you can't realize those exciting design
| visions with just Airtable and the like. Those engineers
| aren't useful because they can write code; they're useful
| because they'll (hopefully!) think through those change
| management and schema design considerations, building
| something that will be maintainable in the future. It's a
| good thing to have a design tool that incentivizes a level
| of foresight before launching a product that's meant to be
| best-in-class.
| gherkinnn wrote:
| > Another example that kept turning up was that the ticket
| "1 phone number for a customer is not enough, support 2
| phone numbers" is inevitably followed by "2 phone numbers
| is not enough, support 3 phone numbers"
|
| Zero. One. Infinity.
|
| https://en.m.wikipedia.org/wiki/Zero_one_infinity_rule
|
| YAGNI, handle a singular case, and once you have multiple
| treat it like a list.
| PaulHoule wrote:
| In the case of the phone number or email it is just so
| frickin' predictable what will happen.
|
| Adding multiple non-list fields is seductive because
| going to the list is a "structural instability" that
| requires using different coding techniques.
|
| Right now I really like https://www.react-hook-form.com/
| for forms that have list values. Back in the day there
| were a set of techniques that seem forgotten (like how
| the Egyptians built the pyramids) that some developers
| knew and others didn't.
|
| It isn't hard at all to make a no-JS form where you had
| an "add" button next to a list of values. When you click
| on that button the POST data contains everything in the
| form as well as the key/value pair for that particular
| button (and not other buttons) so the back end can tell
| which button was pressed and redraw the form with another
| field. Delete can be handled the same way. If your form
| is not junked up with 50MB of trackers and ads and
| metadata for every social platform it is really fast, it
| _was_ really fast even on dialup.
|
| With a handful of helper functions and a "router" that
| can display different forms depending on what you enter
| you can make powerful no-JS forms but that knowledge
| didn't quite reach 100% penetration before Angular came
| along, but developers who came on after that never
| learned it.
| gherkinnn wrote:
| I must say, React Hook Form offers a good way for React
| to interact with forms. There are many things to dislike
| in that ecosystem but that lib is excellent.
| 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.
| screaminghawk wrote:
| > I'd like to see no-code UX patterns that losslessly map
| onto the underlying abstraction. That way you can use the UX
| pattern until it gets too tedious, and occasionally dip in-
| and-out of the code-view in a non-jarring manner.
|
| What are you describing sounds a lot like Saleforce and other
| CRM systems. Often the code implementation get hidden away
| when it's not something native in the no-code solution. Then
| "magic" happens and you don't quite know why until you dig
| into the code again.
| sillyfluke wrote:
| >Code is merely the leanest human-readable representation for
| loss-less specification of requirements.
|
| I think you might have meant "loss-less specification of the
| current design." requirements are aspirational, and signifies
| the intent, code is the loss-less version of how the system
| will actually behave.
| screye wrote:
| No, I meant requirements.
|
| Stated otherwise: "Sufficiently advanced requirements are
| indistinguishable from code".
|
| Abstracted requirements define outcomes. Fine-grained
| requirements define code.
| sillyfluke wrote:
| I respectfully disagree.
|
| The customer has given a requirement that states the
| variable <y> has to be calculated as y= x +1.
|
| However, the code that exists has been implemented such
| that <y> is calculated as y= x - 1.
|
| y=x-1 is how the current system behaves. However it
| conflicts with the actual requirement, which is y=x+1.
| 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?
| gyomu wrote:
| > I've never really understood the need to build a full
| fidelity reproduction of the layout systems a design is
| targeting.
|
| Well, you wrote why right before:
|
| > As a dev that does a lot of his own design
|
| You understand the whole, so you don't need lossy
| abstractions to connect the ends. When roles are specialized
| and people only understand part of the context in which
| they're working, they need ways to communicate about the
| whole thing.
|
| Tools like Figma fill those sort of gaps, that tend to occur
| in organizations with dozens/hundreds of employees, with the
| need to quickly onboard frequent new hires, etc.
| cryptozeus wrote:
| I have totally opposite experience working on large ds at uber
| brulard wrote:
| Would you elaborate?
| 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
| The5thElephant wrote:
| Figma on desktop is an Electron app I believe. Figma chose
| to build a custom webGL rendering engine for their design
| canvas, so the core issue is that technical decision early
| on (probably allowed for some better performance and
| multiplayer back then). Figma is stuck with wanting to
| control their rendering and allow for non-product stuff
| like Figjam or the new Draw tools, but it will inherently
| hold them back from providing a really good design/dev
| handoff and always will hold designers back because it
| doesn't use CSS web rendering.
| 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.
| Vinnl wrote:
| I haven't used it myself yet, from what I've heard, Penpot is
| closer to filling that gap? https://penpot.app
|
| And it's free and open source.
| sghiassy wrote:
| I think the authors point, is that, designers are incorrectly
| choosing the wrong tool.
|
| In my experience in FAANG, designers use Figma for everything.
| Like literally everything.
|
| So when you say, they should use a sketch tool when they need
| free form, they don't
| carlosjobim wrote:
| > If there's something better than Figma out there, please, let
| me know.
|
| HTML+CSS works very nice for these mock-ups. Tried Figma and
| Sketch for a small project, never again.
| 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
| Hammershaft wrote:
| Exploratory design isn't for crafting padding overwrites and
| call to action tweaks...
|
| It's for thinking from first principles about the problems
| users face, and how to shape the products we create to best
| help those users overcome their problems. This means
| reconsidering faulty assumptions about the nature of the
| problem users face & the shape of the product that best
| solves that problem.
|
| I hate this shift of the role of design in software towards
| trivial aesthetic fixations.
|
| Design should be a shared discipline that orients product
| development towards greater value for users, but as of late
| it's mostly a trendy & low value extension of marketing.
| zdragnar wrote:
| Visual design, interactive design and information
| architecture are all lumped together under UX, but there's
| little call for going back to first principles when you
| have an established design system.
|
| When you do, you end up with prototypes that are
| disconnected from what exists, and don't look good when you
| actually start using the existing visual design system.
| That's where all the one-off tweaks start coming in.
|
| Unless the business is willing to pay for research into a
| holistic change to the semantics of the existing design
| system, Figma is perfectly suitable for the majority of
| design work once a cohesive design language has been put
| together.
| pcurve wrote:
| Figma has neglected its core audience - the designers.
|
| Instead, it is trying to be all things to everyone, except it's
| serving no on well at this point.
|
| And it all started with FigJam. Still a half-baked product
| trying to take piece of pie from Miro.
|
| Then they released Dev Mode to extract more revenue. Now Figma
| Sites to compete against web build/hosting sites.
|
| So many half baked products, it's frustrating. They're abusing
| their monopolistic position in the market.
|
| there will be a time where they'll have to pull a Google and
| retire products that never worked out.
| 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...
| karaterobot wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| Hammershaft wrote:
| > Don't worry, no engineer I've ever worked with has shared
| your confusion.
|
| I have seen nontechnical product managers share this confusion
| to the strong detriment of projects.
| zelphirkalt wrote:
| I am not using Figma at all. Not a designer, and I know CSS, at
| least the part I am using and am not afraid of looking into it
| more when I need more. For example recently I wanted a grid
| layout, that has at maximum 2 columns and wraps to 1 column
| when not sufficient space for both columns is available, so I
| looked up how to do that.
|
| "Ready for dev" -- If we expand that abbreviation, then it
| would be "ready for development" or "ready for developer", so
| the actual literal meaning to me seems to be: "Now you can show
| this to a developer so that they can _properly_ develop it."
| and not "Now put this onto your production website, you are
| done!"
|
| Might be that many people get confused though.
| dandano wrote:
| 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 wrote:
| Meh. Figma is for UI designs, not "Design", in the sense of what
| Creative Review mag etc
| ripped_britches wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-08 23:01 UTC)