[HN Gopher] Will Figma become an awkward middle ground?
___________________________________________________________________
Will Figma become an awkward middle ground?
Author : ridd_design
Score : 84 points
Date : 2024-07-24 19:22 UTC (3 hours ago)
(HTM) web link (www.dive.club)
(TXT) w3m dump (www.dive.club)
| egypturnash wrote:
| How shitty is Figma's current "export as css/html/js"
| functionality? How many people do you think they have working on
| improving that? How many of the people Figma is paying to fool
| around with AI do you think are experimenting with building an AI
| stuffed full of css/html/js tokens, and other functionality for
| improving Figma's ability to pick up working css/html/js, tweak
| it, and re-export it?
| refulgentis wrote:
| I don't know if these are supposed to be leading questions, or
| questions combined with assuming an answer to make a point, but
| tl;dr code export is good.
| ridd_design wrote:
| How incentivized is Figma to invest in a world where fewer
| developers pay for seats is the real question
| usaphp wrote:
| my problem with Figma is that it became too technical and code-
| like. By the time I finish setting up layouts, paddings etc...I'm
| catching myself thinking - why didn't I just code it straight up,
| could have been as fast.
| game_the0ry wrote:
| This will come off as a humble brag, but I will say it anyway.
|
| Right now, I am tasked with building a PoC for a new product my
| team wants to build by the end of the quarter. We have one big
| problem - we have no designer on staff. But we do have a design
| system with a library with re-usable react components and
| tailwind css, and those are things I am pretty good with. So I
| have full autonomy when it comes to turning product requirements
| into a live demo. I was able to accomplish quite a lot in a short
| period of time with no designer and just my own taste in design +
| ux. And product stakeholders were pretty satisfied, which means
| the outcome was productive.
|
| So from my perspective, Figma is not only an awkward middle
| ground, but not even necessary for me.
| ctward wrote:
| I think in the future product designers will shift into two
| factions. Live code generation and design system development.
| Design systems will be the backbone of any quality AI interface
| generation system. How we build those design systems will be
| the interesting part. Will most people unify around
| material/carbon or will they invest in house teams to ensure
| their UX doesn't fall behind the competition?
| brigadier132 wrote:
| My experience is that you should never code and design at the
| same time for non-trivial products.
|
| When I'm doing design work, there is a product spec already
| defined but it almost always changes once initial designs are
| completed and people have a better understanding of how it
| would work in practice.
|
| If you were to code and design at the same time you would
| inevitably writing some logic as well and this often turns into
| wasted effort.
| asoneth wrote:
| Came here to write the same.
|
| I used to teach at a UX grad program where students were
| required to learn both design and development. But doing both
| on the same project was almost always a mistake -- the
| designer has to deeply understand and advocate for the end-
| user's mental model while the developer has to deeply
| understand the technical model and constraints. Attempting to
| do both often end up conflating them or compromising on at
| least one of them.
|
| Sort of like how many lawyers are skilled enough to handle
| either prosecution or defense but few do both on the same
| case.
|
| I think there's a Nielsen/Norman article on this but can't
| find it at the moment.
| game_the0ry wrote:
| > When I'm doing design work, there is a product spec already
| defined but it almost always changes once initial designs are
| completed and people have a better understanding of how it
| would work in practice.
|
| In my case, I am just iterating on the fly with our end-
| user(s) (we also do not really have a product owner).
|
| It may not have been obvious, but I am working on an app for
| internal stakeholders, not for external customers (the
| customers that my company serves).
|
| So when it comes to designing for external end user +
| customers, design is serious and necessary consideration,
| which is where Figma would come in.
| jauntywundrkind wrote:
| Worrying about wasted effort spent breathing some life into a
| mockup/prototype
|
| vs Worrying about creating some figmentary Figma imaginarium
| that wont translate well into the actual app
|
| I do think there is a risk, it's just not of throwaway code
| (the effort of that throwaway is vastly smaller than what
| this path replaces). The risk is more how & where the future
| could be constrained. If the prototype starts becoming the
| app, there's some risk the prototype imposes poor app
| architecture. If the prototype starts becoming the app the
| effort to mock/prototype new ideas risks becomes higher.
|
| I strongly agree with the parent about getting in there &
| trying things semi live, not being afraid to wade in. The
| component offerings are excellent today, don't wire most of
| them up, just throw them on the screen as best you can & put
| in minimal stitching or hardcode a forward/back through
| states.
|
| The fear of this going bad is way outsized. The design
| industry needs to get where the puck is going & stop playing
| around with fancy abstract design tools.
| brigadier132 wrote:
| I don't code and design at the same time because I've
| noticed from experience that it's slower and gives worse
| results than designing first and then coding.
|
| The wasted effort is one factor to it but another factor
| may be that I'm able to just focus on design and ux more
| and not think about implementation.
| fantasybuilder wrote:
| This has always been the case. Zero to one with a single
| developer or a very small team is the most exciting part of the
| lifecycle of a project. Medium to large size companies have
| very different challenges.
| snide wrote:
| I feel seen!
|
| I'm one of these codey designers. The madness that exists in
| modern design teams (I used to manage a team of 50!) is insane.
| There's a lot of time spent on "design systems" in Figma. Very
| generally Figma is not the website, and the effeciency additions
| of building tools there is a lost cause.
|
| Modern CSS and your JS frontend of choice is a lot quicker and
| more powerful for component building and general design work.
| There's way too much to do with media break points and
| tokenization there. There's a misguided group of designers that
| are learning a lot of esoteric Figma features that don't
| translate into something users will ever touch.
|
| 10 and 15 years ago designers needed to learn the code part too.
| Somewhere along the way we put them in a corner and made learn
| these prototype tools.
| chatmasta wrote:
| Agreed that in most cases all this extra work and attention to
| detail is essentially wasted effort that never sees the light
| of day.
|
| But it's possible to extract value from it if you have a
| culture where designers build prototypes, and you can use those
| prototypes for user testing, feedback, demos and pitches, while
| the code is being built. But it's rare that companies have this
| culture.
| ketzo wrote:
| Really good (and underdiscussed) point that Figma designs are
| not _just_ for consumption by developers.
|
| I know this is a cliche phrase, but when you're trying to
| align stakeholders (PM, manager, VP, dev lead) on a product,
| it is genuinely very useful to have really nice, hi-fi
| mockups to make sure everyone is talking about exactly the
| same stuff.
|
| It's also definitely a scale thing. If you have 500
| developers, it's probably worth putting in some extra sweat
| just to make sure they're all using the _exact_ same button,
| etc
|
| If you have 10 devs... yeah, hard to justify a super-
| perfectly-polished design system for every single bit of your
| frontend, IMO.
| uxcolumbo wrote:
| I wouldn't call Figma a prototype tool. It's pretty bad at
| prototyping sophisticated interactions.
|
| They are canvas based clickable mock-ups with fancy transitions
| and a few more things.
|
| But it can't generate / export to HTML which comes in handy
| when you need to use it offline.
| dexwiz wrote:
| Figma puts codegen on plugins and partners. These either
| generate generic html or, more commonly, platform specific
| code.
| tiffanyh wrote:
| > There's way too much to do with media break points
|
| As someone who has been handwriting HTML/CSS for literally
| 25-years, I'm still shocked dealing with media break points
| isn't easier.
|
| It easily snowballs into you having 3 different CSS
| (phone/tablet/desktop).
|
| I wish there was something akin to 'light-dark' (where you can
| specific a different value conditional on the environment) but
| would be trigger based on window size.
|
| e.g. font-size: window-size(1.2em, 1em, 0.8em)
|
| Which would translate to, if the browser window is small
| (phone), use 1.2em ... if browser window is large (desktop),
| use 0.8em
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...
| lstamour wrote:
| If you want responsive page elements that change styling as
| you reflow the page, we have that now - container queries -
| https://developer.chrome.com/blog/css-ui-ecommerce-cq but
| it's still somewhat new, and nobody's existing design systems
| support them yet. People (myself included sometimes) still
| prefer using JavaScript for this stuff. It'll change over
| time, though. (Also I've been wishing for this for almost two
| decades now, so I'm glad to see it arrive!)
|
| Edit: Though even simpler than that is the width media query,
| which I think you might be looking for:
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/widt...
| tiffanyh wrote:
| Thanks for sharing.
|
| I've just found that approach very clunky in practice,
| hence my comment about it snowballs into effectively having
| 3 different CSS (phone/tablet/desktop) and wrapped in media
| width queries.
|
| Though maybe I use it incorrectly.
|
| I'm always open to learning something new :)
| lstamour wrote:
| Well, I'm not sure of other syntaxes to make it simpler,
| but you could use a CSS variable to make it a little
| easier: https://developer.mozilla.org/en-
| US/docs/Web/CSS/var Especially if you re-use the same
| padding values for multiple parts of the page/site. Then
| you won't have to update values in 3 different places for
| each padding/font-size/whatever rule. Instead just set
| the variable for each @media width and then in your later
| rules, use the single variable to refer to the correct
| value for all breakpoints.
|
| Also, some units cascade. So if you set the top-level or
| parent to a particular size, then child elements inside
| can inherit (or ignore) the unit. This means at a top
| level you can set your font-size for each @media width,
| and then use relative units and it will inherit down. But
| that only works for very small websites, because it
| introduces subtle bugs as you incorporate more controls
| from people not aware of your particular practice.
| tiffanyh wrote:
| You can't use variables in the media query itself.
|
| https://stackoverflow.com/questions/40722882/css-native-
| vari...
| reducesuffering wrote:
| I'm partial to the TailwindCSS approach where they're
| right next to each other like:
|
| <div className="text-sm lg:text-lg"> Hello World </div>
|
| I don't know how resizing defaults would work well for
| most cases instead of specifying what you want.
| earthnail wrote:
| The closest I've come to that was using Tailwind.
| text=[1.2em] md:text=[1.0em] lg:text=[0.8em]
| tomr75 wrote:
| doesn't tailwind do this?
| omnimus wrote:
| Tailwind doesn't to anything special here. Its just css
| media queries.
| omnimus wrote:
| I am not sure if you are joking but there is whole set of
| techniques called fluid typography that does this (using css
| math functions mainly clamp) https://fluidtypography.com/
| It's not a silver bullet and many people simply don't prefer
| it to having a few breakpoints (that includes me too).
| paul7986 wrote:
| Been a front-end designer since I started learning/my career
| (2007 lol) and sorta hate having to use Figma yet it's a lot
| like using Photoshop so it's not too bad. Yet I almost always
| just design/code in the browser using the "Inspect Element,"
| tool (take my last design project, deconstruct it as needed and
| then copy and paste the code into an IDE; click refresh fairly
| often).
| H1Supreme wrote:
| > Modern CSS and your JS frontend of choice is a lot quicker
| and more powerful for component building and general design
| work.
|
| I'm a former designer turned programmer, and I couldn't agree
| more. I was recently tasked with doing some mockup images (no
| official designer on the team), and at the end, I realized that
| I could do it so much faster with code.
|
| Ironically, while I was putting the images together (I used
| Affinity Photo), I remember thinking to myself "Does this thing
| have some sort of scripting language?".
|
| I still think a sketchpad and a pen is the best way to generate
| ideas. But, when it comes to mockups, good old HTML and CSS
| really can't be beat.
| willsmith72 wrote:
| Hard disagree here. Are you writing production code, or are you
| building mockups/prototypes?
|
| I don't want non software engineers touching production code.
| It's too hard, and the depth of skillset for a product/UX
| designer is already huge.
|
| If you find css and js faster for prototyping and mockups, then
| sure. I'm doubtful and still yet to see that work in the wild.
| garrickvanburen wrote:
| My math is closer to 18 years.
|
| At the time I was selling UX services, and the 'prototyping
| tools' of that generation were what drove me learn PHP, Ruby,
| and Javascript - for all the reasons you state. I was baffled
| by all the time and energy people spent becoming an expert in
| the prototyping tool rather than an expert in building for
| real. I declared these prototyping tools an expensive
| distraction and never looked back.
| xnx wrote:
| Figma is a cursed midpoint between useful and easy to make
| wireframes, and a functional working interface that can be
| refined later.
| rbancroft wrote:
| Interesting, I really like balsamiq and still use it personally,
| despite work being a figma shop.
| tracker1 wrote:
| Used to use it a lot, still like it and the handful of times
| I've needed something similar, it's what I reach for.
| brrrrrm wrote:
| Empowered with chatGPT (now claude), my partner as a designer
| pulls off extremely workable implementations of all different
| ideas without much need for sketching in a non-functional design
| tool.
|
| When she does draft in design tools it's usually more graphic in
| nature (branding etc).
| ctward wrote:
| my push back on this is that unless you have a pretty robust
| visual design system the outputs are going to be incredibly
| unoriginal. Yes it will make solving UX problems faster but at
| the cost of visual differentiation. There is always going to be a
| place for high fidelity exploration for styling innovation and
| brand identity.
| ridd_design wrote:
| it's a good push back. I do think this assumes some (small)
| design language to extrapolate. But that's also something that
| will become borderline free in an AI world so I think it's a
| safe assumption.
|
| What's more interesting that doesn't exist yet is the ability
| to create more compelling visual languages/systems based on
| inspiration screenshots. That's a big unlock IMO. Everything
| right now is very generic.
| refulgentis wrote:
| There's this, which is more "will we fire all the designers?"
| (No), and there's the other massive problem: they were a nice,
| simple, web-native thing that was easily positioned to displace
| Photoshop and Sketch.app.
|
| They never really successfully landed things that we used to call
| "major version bumps" and it's devolved into quite a mess. Not
| anywhere near Photoshop-level, but...it's a strange situation to
| me because you could build a successful business based on the
| premise of "that, but only 60% of it, with 5% of the headcount"
| novok wrote:
| As a mobile engineer, I do not have the visual & product skills
| that designers have. They can create something visually
| appealing and aligned much faster than I can and have all sorts
| of skill sets that take a while to hone. I might have more
| taste than the typical backend engineer, but it doesn't really
| translate to visual skills to the level of most designers.
| GenerWork wrote:
| Figma is a tool and nothing more, despite some people to turn it
| into the end all be all of user experience. It will eventually be
| replaced with something, just as it replaced Sketch, and just
| like Sketch replaced Illustrator. I also noticed that the author
| barely touches on the people who make the interfaces (product
| designers). If the author gets their wish, businesses won't
| hesitate to axe their UX teams to save some costs.
|
| Disclaimer: I'm a product designer who is very skeptical of the
| enthusiasm around AI as I can see a future where product will
| instead rely on AI instead of designers to create interfaces.
| ridd_design wrote:
| author here I'm also a product designer! I'm skeptical of the
| current approach to AI-generated interfaces. But am a big
| believer that AI will fundamentally change the way we design
| products.
|
| My high-level hypothesis is that in the same way browser-based
| design (Figma) displaced Sketch... code-based design will
| displace Figma. It will start with the longtail and smaller
| teams. Figma has a stranglehold on enterprise. But I refuse to
| believe I will be making vector pictures of products in the
| longrun. It will feel as easy to design interfaces in code. The
| article is an attempt at discouraging text-based prompting in
| that world though. I'd much rather have a modern
| sketching/wireframing tool connected to my code base and design
| system.
| chamsom wrote:
| Getting designers willing to setup their workstation to hand
| code a React app with dozens of dependencies and be constrained
| by the DOM is not going to go very well. And then doing it all
| over again with several other web libraries/languages. This is
| not even design, it's a developer role who just happens to
| paint UI with code.
| tracker1 wrote:
| As a programmer, I find that much more than a wireframe guide is
| distracting. That said, I tend to have a good understanding of
| the UX rules for a given design style (often material) and the ui
| library/tools I'm using. Sometimes I might have questions about
| the interaction.
|
| On the flip side, I've seen developers that just about need a
| functional example to work out anything and will still have
| issues with real functionality. So YMMV.
| legitster wrote:
| As someone who develops email templates, you will never
| understand my pain. Figma creates a complete fantasy world for
| designers who do not understand that a pixel and color perfect
| design is going to be smashed to bits by the client.
|
| Also, I feel the rise of React is partially to blame. CSS
| frameworks were clunky and constraining - but they forced you
| into a lot of design constraints developed on years of best
| practices. I can't tell you the number of React-based enterprise
| tools I have to use on a daily basis that have picture-perfect
| designs ... that turn clunky and confusing the minute you resize
| the window or activate an animation.
| willsmith72 wrote:
| That's just bad designing. Good designers use the Figma
| equivalent of flexboxes and develop responsible designs.
|
| How is this react related? You could always write crappy css. A
| team creating non responsive react apps would not create
| responsive non-react apps
| omnimus wrote:
| They said email templates. That means no flex/grid/typefaces
| etc etc. emails are painful caveman html
| jjcm wrote:
| > Figma creates a complete fantasy world for designers who do
| not understand that a pixel and color perfect design is going
| to be smashed to bits by the client.
|
| Figma employee here. I'm curious if you see this as a mistake
| of the design tool itself, or if this is endemic to the
| constraints of html emails? Maybe phrased a better way, what
| would you like to see to help convey these constraints to
| designers?
| tazu wrote:
| Slightly off-topic, but I dislike this trend of "designers over-
| designing everything". This website is aesthetically pleasing,
| and has it's own unique style, but scrolling the home-page is
| laggy on my $4,000 Macbook (Chrome). I guess it's because it
| downloads 14MB of resources and tries to download more based on
| scroll position?
| d3vmax wrote:
| When is the last time you restarted your mac? I had this guy
| complain to me, everything is laggy and chrome is slow (memory
| leaks?). A simple restart fixed everything. Clear your chrome
| cache/etc. Disable all extensions you dont use and try again.
|
| If it does not, try another browser.
| urban_alien wrote:
| Same for me on FF Android. Unbeliveable sluggish scrolling.
| Couldn't read the article.
| FractalHQ wrote:
| Strange... my iPhone renders it instantly with 0 issues.
| toddmorey wrote:
| I think Figma is fairly interested in lofi mockups too thus
| Figjam.
|
| Their components aren't code exactly but I think that's because
| they will ultimately directly output / sync full components to a
| variety of platforms from their abstracted representation.
| grumple wrote:
| Figma is for people to share and collaborate between team
| members. Especially between designers and devs, but devs at my
| company use it directly as well. You get something picture
| perfect that others can comment on or tweak. You can update it
| easily. Try out different colors or images or icons rapidly. You
| then also have visual documentation that can be sent to business
| people or partners.
|
| If it's just you, you don't strictly need it. Personally though,
| I find it really useful precise because I'm not a great designer.
| I can fiddle around with sizes and layouts in figma until I get
| it the way I want it, then I turn that into code. I could jump
| straight from scribble to code, but having that middle step where
| I can exercise the idea without screwing with components or css
| feels nice.
| mvellandi wrote:
| I find Figma useful for quick ideation on small projects to see
| potential constraints and challenge assumptions. The lower-fi,
| the better. I only do mobile-design to focus on essentials, use
| grayscale colors to not be distracted, and don't make a mobile
| global navigation. If it was a larger project though, I'd
| definitely consider sketching as the speed is so much faster. And
| then jump into code.
| novok wrote:
| Figma could adapt by making something that actually produces code
| well too? Although it would add a lot of complexity and designers
| might not like having to make different versions for different
| platforms, like the 'android', 'ios', 'flutter', 'web', etc.
| There are tools like judo.app that make 1:1 native SwiftUI
| designs.
| dcchambers wrote:
| Note: Professionally I do practically nothing with the frontend
| of web development, so my experience may be far from normal, but
| when I do have to do something frontend related for personal work
| or the rare work-related task, I prefer a very rough wireframe
| using something like https://excalidraw.com/
| permo-w wrote:
| I honestly cannot understand the hype around figma. it's such a
| weak product. it's laggy, the interface is not fantastic and it
| isn't even able to convert the proposed interfaces to code?
|
| why would I want to use figma when I could use a non-laggy
| product that can convert my designs to code?
| kajecounterhack wrote:
| If you work on a big team, collaboration is everything. Figma
| enables collaboration in a way that very few other tools allow.
| SOTA before Figma was sketch files in dropbox or emailing them
| back and forth.
|
| A lot of commenters here are lamenting the practicality of
| modern design culture (which is often centered around figma)
| for smaller teams / earlier projects where collaboration may
| not be as much the bottleneck. The tool itself is still very
| useful for small team collaboration though, and for folks
| thinking through ideas without having to code them up.
|
| Figma also pioneered putting complex tools into the browser.
| Today people take multiplayer and 60fps canvas for granted but
| Figma basically created the space. It was a humongous technical
| achievement and continues to be a very difficult thing to copy,
| though folks are obviously trying (e.g. Penpot).
|
| AI conversion of components to code is WIP for all toolmakers
| but obviously on the roadmap. Another hard problem you're kind
| of trivializing here.
|
| > why would I want to use figma when I could use a non-laggy
| product that can convert my designs to code?
|
| Can you list some examples?
| whoisjuan wrote:
| I'm a designer. I built brainglue.ai without Figma, a design
| system, or a UI library. I just went directly to code
| (react+tailwind) and let a style organically emerge.
|
| I'm not saying that I'm a unicorn and that my idea-to-code-to-
| design execution is flawless, but I certainly believe that in
| this situation, if I hadn't done it this way, I wouldn't have
| done it all. However, doing this would be wasteful or dumb in
| almost every other situation that requires my design output.
|
| People pay for Figma precisely because it's a middle ground. It
| was a middle ground before, and it will continue to be unless
| something fundamental changes.
| jay_kyburz wrote:
| Nice design!
|
| Small suggestion, I would preload the contents of each tab and
| the images in the circle after the main content is loaded.
| There was a good two second lag loading the images here in
| Australia.
| whoisjuan wrote:
| Ohh nice catch. Will do. Thanks
| jjcm wrote:
| Major bias disclaimer:
|
| 1. I work for Figma
|
| 2. I work on AI at Figma, as well as on the design systems part
| of the product
|
| 3. Prior to Figma, I spent 7 years as a prototyper teaching
| designers how to go from idea->code without a design step in
| between
|
| I love designing in code, and I HIGHLY recommend you do so for
| smaller projects, but I disagree with some of the assumptions the
| author is making. The author states, "The reason Figma has over 4
| million users is because it takes most people too long to code
| their designs", which I feel is inaccurate. For less-experienced
| creators, it's mainly because the UX is more approachable in a
| design tool. That's less relevant here since the author is
| talking about designers who can code. For the most experienced
| designers, it's more about alignment.
|
| As an example, most of my side project[1] was designed entirely
| in code... until it got to a certain scale. Designing in code was
| amazing early on when every page could be a new pattern. After a
| while, managing variations of components and ensuring that I
| wasn't diverging from existing patterns became non-trivial.
| Things became even harder when I hired another person to work on
| things. At that point, alignment became crucial. We needed to
| ensure that designs we were both working on were aligned with
| each other. Patterns one created needed to be reused, not
| reinvented by the other. This is something that's very hard to do
| in code. I ended up creating a mirror of the existing
| implementation of the site in Figma from scratch. For the iOS
| app, I ended up starting it in Figma[2] so we could easily
| compare implementations and land on an agreed pattern. Alignment
| with patterns and with the team was the #1 reason why we operated
| in a design tool during this time.
|
| [1] https://non.io
|
| [2] https://www.figma.com/design/im8a7L7axmbj0S0lm27NKa/Nonio-
| iO...
| jmull wrote:
| > But you know what AI will be great at? > ...Turning wireframes
| into frontend code (limited logic) > ...Wielding (and
| extrapolating) your design system > ...Creating beautiful visuals
| from screenshots and mood boards
|
| I don't think the argument works. It imagines AI will be able to
| do things that our current AI do not.
|
| Our current AI work in terms of what they've been trained on.
| Natural language to code works as well as it does because coders
| have been asking and answering questions about code a lot on the
| internet, that's been collected into data sets, and those data
| sets have been used to train LLMs.
|
| For AIs that work like our current ones to be great at the things
| the author envisions, they will need a _lot_ of examples of those
| things, and of a high quality too.
|
| The author wants AI to turn natural language into wire frames,
| let the designer adjust and improve the wireframe, and then turn
| the improved wireframe into production code.
|
| But I don't think the training data for those two transformations
| exist. What even is the intermediate wireframe format? AU will
| produce and consume it, but it also needs to be in a form human
| designers can iterate on.
|
| Since the training data doesn't exist, it would need to be
| created. Is that feasible? If you can't harvest the internet for
| it for almost nothing, it would cost a great deal to create, and
| I wonder about the quality of the result.
| fantasybuilder wrote:
| Frankly, I am not even sure what "frontend code" means in this
| context. What stack? How is state managed? How is this code
| integrated into the larger production system? If by "frontend
| code" they mean fairly clean React code - that's just a small
| subset of what is actually needed for production.
| willsmith72 wrote:
| Exactly. It's a dreamland where frontend styling is
| completely decoupled from logic and behaviour. Sounds good
| for a 2005 web designer.
| karaterobot wrote:
| I think the assumption here is that once you make a component
| library in code, you can just map low-fidelity wireframe
| components (from something like Balsamiq) onto those "real"
| components, and go from a napkin sketch to a functioning website
| without the awkward middle ground of vector designs and clickable
| slideshow prototypes.
|
| It's an interesting idea. I'm skeptical that, in the real world,
| you can reliably infer everything you need to produce code from a
| simple wireframe: how do you deal with specific interactions,
| specific data, specific operations on that data? Balsamiq-style
| mockups are all about _not_ getting specific, in order to keep
| the fidelity low and the velocity high.
|
| In practice, with Figma, the thing I've noticed is that I use
| low-fidelity wireframes less than in the past, because it's just
| as easy and fast to use high-fidelity components from my design
| library. If I'm just stacking Lego blocks together to make a UI,
| why would I use low-fidelity blocks, if I already have high-
| fidelity blocks that are much less ambiguous?
|
| In other words, I'm not sure Figma is in the middle ground
| between sketches and code anymore, I think it's just as easy to
| think of it as a brainstorming tool that happens to produce high-
| fidelity results if you use it right.
| arnaudsm wrote:
| I'm both an engineer and designer, and I really dislike the
| complexification of Figma.
|
| I use Figma to sketch without any constraints, which allows to be
| more creative than programming right away.
|
| But nowadays everyone is using complex layout systems and
| component libraries with 10 nested levels and constraints all
| over the place. The new dev mode made it even worse. Even when
| you know all the shortcuts by heart.
|
| The friction is so insane, Figma became slower than programming
| itself !
| max2 wrote:
| I can see authors point when it comes to smaller website or app.
| I work on enterprise products that are rather complex with large
| surface area. Despite being a pretty good coder (or at least used
| to be), I wouldn't attempt to iterate on changes directly in the
| code and link all the flows etc. It would take much longer and
| I'd lose ability to make rapid changes.
| shove wrote:
| Figma passed on my resume, so I'm not particularly incentivized
| to leverage my (very deep, thank you) engineering / design / UX
| expertise and offer my product guidance for free. They have a
| _ton_ of momentum, so there's a lot of room to make mistakes
| before it shows up as more than a blip in the quarterly numbers.
| They'll _probably_ be fine without me, but seems like an
| unnecessary risk. ;)
| infomiho wrote:
| Somewhat related: tldraw has amazing demos of generating code
| from sketches https://x.com/tldraw/status/1814046549522964692
___________________________________________________________________
(page generated 2024-07-24 23:15 UTC)