Why Figma Wins | Hacker News Reader

Why Figma Wins

kwokchain.com

385 pointsadriand181 comments

We use Figma at work, and while it’s a nice tool I think it’s easy to fall (or maybe we just fell) into a kind of uncanny valley. The designs we get are close to realistic mockups of our actual UI, but are often not 100% there, and it’s the little deviations that can be quite distracting.

Engineer: So are we changing the nav icons as part of this story, too?

Designer: Oh, no, ignore that. I didn’t have our real icon set so I just grabbed some others

Engineer: This modal doesn’t look like our normal modal, are we supposed to be building a new one?

Designer: Oh, no, ignore that - I’m working on a design for a new modal and I just used that here

Engineer: Ok, do you know our current modal doesn’t support X, so this part of the interaction won’t work?

Designer: Oh, okay, I’ll go update the design I guess

Etc... sometimes makes me wish for the days of Balsamiq / sketch style designs where the idea was to not try to make it photorealistic.

Having said that I guess if you could get Figma completely in sync with your actual UI it’d be pretty nice.

EDIT: I will add that the clickable mockups seem really helpful for our Design team when they're doing user testing, which is happening before the designs get to us. But this is not unique to Figma, InVision can do it, too.

I've encountered this as well. I am a proponent of just using low fidelity shapes for mocks instead of high fidelity renderings of what it should actually look like.

If you put enough work into the design system, and implemented it well for use in code, all you should NEED is a low fidelity shape telling you where to put existing components, and how to string them together. Everyone already knows what a modal looks like, behaves like, etc. they don't need it designed for them every time it comes up. That just wastes everyone's time.

I second this. The most efficient frontier in communication between engineers and designers is about striving for simplicity by stripping visualization to stick figure like representation.

Exactly!

Design is about how it works. That’s more important than how it looks. Low fidelity focuses designers on the app workflow, lets more of the team get involved in design, promotes UI component reuse, and avoids confusing managers about what’s actually finished.

A few days ago I was searching for a cloud native, low fidelity mock up tool, and liked https://gomockingbird.com/

I have no affiliation with them.

I'll check it out, thanks for sharing! Looks promising from one one minute scan.

In a similar vein (also have zero affiliation) I discovered https://whimsical.com today, which also has a few other promising looking tools like flow diagrams, post-its etc.

Marvel App is a nice one. Sketch, photograph, wire photos together into a workflow mockup.

App Cooker on iPad is really nice too, though no longer maintained. It exports the storyboard of all the UI screens connected by transition arrows.

This is true.

It makes it really easy to first building a design system (like Bootstrap, Material Designs, Antd,etc). Which are a bunch of components, from basics like headers, list, to modal, message, cards, etc.

Then just place those components into the wireframe.

If anything need to update, it will be updated from the design system, then sync to the project

We use a shared Figma component library, which gets implemented as a shared Storybook library for front end developers.

In theory, this means the designers are designing with components which are already represented in code, and as long as they update the library with any new or modified components, it should be straightforward: a change in the Figma library represents a change that needs to be reflected in Storybook.

But that's just the theory. In reality, designers often need to work quickly, and the idea of design debt is just as real as tech debt. Indeed, it's probably more of a problem, since there's no such thing as pull requests or automated regression testing for design, so it's harder to spot problems.

Figma already has a way to at least partially address this issue: they provide analytics that show you which of your components are getting detached, as well as a lot of other useful stuff. Unfortunately, the tier that allows this feature costs about 4x as much as the normal pay tier most people use.

What impact is Storybook.js having on your team?

I’ve recently started using it with my team and the impact has been positive. Component sandboxing seems to encourage developers to encapsulate CSS within web components. Sandboxing also seems to encourage thinking about web component APIs and designing them for reuse.

How well is Storybook.js catching on as an emerging standard in UI development?

We like Storybook a lot. It's made communication between Design and FE a lot smoother. I wouldn't say it clears up all ambiguity, or eliminates all redundancy, but it's a noticeable improvement over relying on institutional knowledge alone!

When I joined about six months ago, the team was already using it, and keeping it up to date had become ingrained in the culture. I had nothing to do with it, so I can say it's been a good decision.

I have no idea if it's catching on in the wider world! Anecdotally, of the five places I interviewed at last year, two of them claimed to be using it.

There actually is proper version control for design! Abstract being the most fully featured, although only Sketch was supported the last time I checked. But yeah, in my case design debt is usually mainly born during exploration or when designs have a tight deadline and I don't take the time to organise my files and creating reusable components. I often end up with duplicates that I have to manually fix from there on out.

That’s not figma’s fault, that’s a team communication and workflow issue. We have that at work too and the solution is to communicate. Have a big red box with text saying the modal is not ready, or simply don’t have a modal until it’s ready. Better stick, create placeholder components and use those. Replace when ready.

Agreed. In my company, your responsibility as a developer is to implement the design as shown on figma, pixel perfect. If something is incorrect on the design, someone will usually have noticed it and fixed it before I get the chance, because there are 4 sets of eyes on it (CTO, PM, Designers, Developer)

It depends on what is being built. Pixel perfect on the first iteration is not a great idea. Because on the first iteration we are usually trying to figure out “does this even solve the problem” and show that to users. After many iterations you have a rough plan. Then you build a quirky mock with existing components you have. Then you let users play with it and find existing rough edges and smooth them out.

Then you build a much nicer version (perhaps pixel perfect) and then have a lot of users play with it, and then your analytics funnels tell you where the bottlenecks are. So you make even more iterations until you make something that solves the problem in a delightful manner and users are going bonkers about it.

The TLDR is, there is no point getting pixel perfect in the first iteration. Good software requires tons of iterations and the entire pm-design-eng-user workflow should be optimized for faster iterations and learning.

A good design system + mockups get your that.

I hope this is sarcasm.

Seems pretty reasonable to me.

If it’s a rough wireframe it can be just that, rough.

If it’s a pixel perfect mockup then it’s a contract for final product IMO.

Of course whether there are that many sets of eyes on it depends how big a co you’re working for!

Pixel perfect? So if a css box-shadow is 11px instead of 12px someone will notice? ...I don't think so

Maybe if the pixel perfect design is diff'd against the final product...

Here's the thing: higher ups, more often than not, have no imagination. If your mock-up is not explicit and realistic, you'll get complaints and worries that it's not polished or that not a lot of work went into it.

Yeah, this is very real to me. Even after explaining what a wireframe is, I’ve had execs very confused why I’m proposing the UI look like black lines on white background. And not just just execs - I’ve had devs try to implement wireframes as-is as well!

Higher ups have imagination... its just not used the way you are thinking...

Their imagination is running wild that the mockup being used in the presentation to them means its an unknown time until its ready to ship..

They are imagining that is past whatever deadline they have in mind for it lol

You're mixing up wireframes and mockups. Wireframes should be used for exploration of ideas and generally laying down different ideas in their simplest form and mockups (high fidelity, in this case) would then be built based on the existing components or displays new features and views.

If the modal in your case doesn't support a feature, it would be caught during the wireframing, before anyone has invested too heavily into any particular design.

Also, if the mockup resembled the actual UI but still differs ever so slightly, it's a sign of an inexperienced designer. Either they haven't properly made the actual functionality clear and the visuals are confusing (should it differ from the current features or not) OR the team is in need of a design system which would be used as a basis for all design visualisations and implementations.

Agreed. And I think there's a certain personality of people who are employed in UX that lean more towards the design than the conceptual side that often get lost in the weeds with this stuff, too, and you'll end up with a series of mocks that look great, smell great, and gosh darn it people like them... but are missing all error screens, corner cases, more complicated states, and leave developers in the dark on the bigger picture.

Back when I was doing iOS development for a bit I had one designer forcing us to go through every single screen and manually override the default vertical font spacing and kerning settings away from the (company wide) framework we were using -- a change that was fairly trivial on Android but a pain on our iOS stack -- and this ended up taking hours that could have been spent on functionality. And made the app harder to maintain, on top of that. But this was really important to this person that the font spacing match their preference, and also be identical to Android's.

I miss simple wire frames. Some of the more productive projects I was on when doing front end work were done like this: product manager / designer gives a rough idea of layout and flow; developer works with them to throw together the simple flow as just raw HTML, really. Iterate, change, modify based on what does or doesn't work. Then the lipstick came later, once that's all nailed down. Less time wasted.

For my own sanity I've avoided front end work at all now, and have been doing systems level work instead.

I think the reality is that most people who originally got into design did so not because they were passionate about user experience, but because they had some artistic sensibility, and design was a field that would let them utilise that sensitivity for aesthetics while also paying them a salary.

Over the past five years or so, the landscape has changed considerably, and many designers have been forced to make a decision to either head down a more UX-oriented path or do something else entirely. The result of this is that we now have a lot of UX designers who never really wanted to do UX, but were forced to adapt and take on a new role due to a changing industry.

Of course it’s leaky, but obviously the cases where engineers built the right thing on the first try because of the clear design are harder to measure.

Also, look! Engineers are talking to designers.

> obviously the cases where engineers built the right thing on the first try because of the clear design are harder to measure.

That's a fair comment.

> Also, look! Engineers are talking to designers.

I think most good teams have had engineers talking to designers since well before Figma :)

I think it helps enormously if the designer responsible for the designs understands about the tech used in building it. I don't think that every UX designer needs to be a full stack developer as well, but when you have the ability to actually talk about the tech, you can also translate the design into something that non-design folks might understand.

I often ended up sitting next to one of the developers, working along-side with him, helping him on the technical issues (reading Stackoverflow and github issues on various repos for example) while he helped me with the designs by challenging and testing as we were wireframing ideas. Kinda like aöpair programming, but for designers and less siloed.

Ah yep of course, I’m just pointing out that those kinds of back-and-forths, Figma derived or not, are a sign of a healthy org. A lack of grumbling around miscommunication often means that no communication is happening, not that it’s going swimmingly.

had a 200 screen mockup in invision handed to me. it was obvious that a few different teams at the design agency had worked on it:

screens 1-25 had a certain nav bar

26-39 had the same nav bar, but everything a few pixels off with a slightly smaller font in off-white, vs white.

screens 40-70 alternated between the first to nav bars, and introduced pull down select boxes with multiple checkboxes in them. the multiple checkboxes represented - in some cases mutually exclusive combinations of things which contrasted with other nav options.

... and so on. Things had to look pixel-perfect - "look, it's a design agency, they put a lot of work in to thinking about how this is supposed to look and work". So.. you'd make the screens exactly the same ('just export all the CSS for each page', etc). But then, when using the app in development, if you went between various screens, and saw the discrepancies - font sizes changes in nav, for example - that caused more negative feedback - "this is broken!".

I tried to demonstrate the design screens were the problem themselves by just paginating between the invision slides - you could see the font sizes jump/change immediately. "now you're just being negative".

I didn't last very long on that project...

It's not just Figma; a project that I'm on has been having basically the same challenges with Sketch/Sympli, and Axure before that. Breaking it into two separate "wireframe" and "mockup" steps has helped, but folks are still rushing to the "mockup" step too soon IMO; lots of things that could have been caught in the wireframe stage are still having to be corrected in the mockup stage instead, pretty much as described by parent. It's a fairly recent change for us, though, so I am hoping that things will get better with practice.

Personally, I'd rather just implement the wireframe (or something like it) and try to iron out the interaction wrinkles there where it's much easier to update the design and you don't have to worry about fonts and spacing nearly as much; once the interaction implementation is nailed down, then I think it's a better time to move on to the mockup. Hopefully we'll get an opportunity to try this at some point, but it was enough of a struggle to do a separate wireframe at all that I'm guessing it'll take awhile ;-)

Yea, we've had the same problem. I've started to ask our designer just show the thing that should be changed, with 0 other context.

An idea for Figma to mitigate this problem: make a browser extension that can export pages to figma documents. That would make it much easier to have up-to-date designs when doing web development.

This is a failure mode I've seen before in other distributed collaboration situations: there is a giant artifact that either clueless participants or homeless tools force everyone to carefully reexamine every time a change is made. If Figma really were all that I guess it would accommodate the futuristic technology called "diffs". Even if your excellent extension idea weren't available, ISTM designers should just maintain a current representation of production in Figma if only to themselves have some idea what's going on.

Possible solution to that problem:

Have a plugin which could turn the unfinished modal for example into a wireframe look & feel and then when you have the right icon, turn it off again.

I remember back in the days Expression Blend had some functionality to apply sketchy lines style (based on Bill Buxton's book - Sketching User Experiences).

Also, the prototyping functionality is still rather basic. Axure is much more powerful and ideal for the early sketching and testing phase.

But I'm sure Figma will have more sophisticated prototyping features in the future.

What does RP exactly do that you can't do in Figma? With the right plugins and component libraries, I dare say that Figma is definitely more powerful than Axure's offering.

I use Axure to prototype enterprise apps, i.e. lots of forms and data grids.

Last time I checked, Figma didn’t support interactive form elements or prototyping conditional branching based on what you type in a form field.

Being able to prototype business logic without having to get developers having to develop something, saves a lot time at early stages when you explore new features with business users and you can also iterate faster and it’s better for user testing as well, as it’s more than just clickable hotmapped images.

I know you could achieve the same with Framer, since you get access to the code, so that’s useful for designers who can code.

Axure is great for designers or product folks who can’t code.

Is the above possible in Figma now?

I tried to switch to Adobe XD, but sooner or later you can't do some sort of thing that is simple in Axure and you are stuck. Simple example. You have a settings page like this:

Setting 1 name [toggle]

Setting 2 name [toggle]

Setting 3 name [toggle]

You want to turn any toggle on and panel with subsettings should appear underneath clicked setting name, shifting down all other settings below. In Axure it is just a checkmark "push widgets below".

Are there powerful prototyping plugins for Figma? I'd love it if the answer is yes.

Axure is horrible for wireframing and a non-starter for visual design, but it has the most powerful prototyping features I've seen by a long shot. Framer is straight up writing React code, so I don't count that as an option for the vast majority of designers.

Why do you think Axure is horrible for wireframing?

I guess that isn't fair. It doesn't have all the layout assistance and plugins that Sketch and Figma have. It is perfectly fine as a wireframing tool.

Ha! If you think Figma is bad for, check out Axure at some point.

I got sucked into using Axure a few years ago and had a blast making interactive, data driven mockups that utilized custom JavaScript to build components.

It was awesome to get some key concepts across but then one day I realized I spent more time fighting the mockup software than if I had just coded it up.

Oops!

Our designers have solved this by making anything that’s still in the mock up phase completely black/white.

Anything that’s actually ready uses the primary/actual colors. It’s actually pretty great apart from 80% of the design being grey at any point in time.

Eh, that line of questioning should be handled by designers at the very beginning or even before sharing designs and can be addressed more generally for all of their designs before sharing any specific one.

Been there, done that. Usually is because you need stronger design/front-end glue (front-end developers with higher than average design skills).

I have experienced this same situation in Zeplin and Invision, so I suppose this is not just Figma.

Seriously that interaction gives ma a headache. Hand-drawn mockups on papers is where I'm at baby. Know HTML, CSS and SVG as the back of your hand. Code 10 modals and dropdowns and you won't even thing about it anymore.

Sounds like a person problem not a tool problem.

Figma approaches design from an engineer's perspective. They have features like auto layout [0], swapping elements in a list, scaling multiple elements at once while preserving each aspect ratio, and so on.

Can you imagine that if designers before this wanted to move an element in a list, they would have to move every single one instead of having some drag and drop swap functionality? That if they wanted to dynamically change a button size for the text inside it, like we can do easily on the web, they simply couldn't?

Basically, Figma is turning design more into something like front-end development, doing things in a design program that engineers could do normally with code. This is because the developers of Figma are themselves coders rather than designers, so they know what real ease of use should look like (ironically). This is the fundamental corporate culture shift that is the difference between Figma and others like Sketch.

Of course, you could go all the way and simply turn the design software into a web/mobile development framework, which is what software like Framer [1] does, which is literally a design software built on React, and it can spit out React code for you once you're done designing.

[0] https://www.figma.com/blog/announcing-auto-layout/

[1] https://www.framer.com/

Soon enough it will be so complicated that designers will refuse to use it and its users will just become frontend developers.

Just like what happened to HTML and CSS.

Framer doesn't spit out React code once you're done. Code used in prototyping is hugely different and unusable in production. And Framer makers know this and openly talk about this, they're not trying to be a code generator.

Well, I've found it pretty useful to hand animation in js as-is for specific patterns (as we actually handle the specific bezier curve animation, timings, etc...)

Sure you may not use the components wholesale but you can still pick out specific parts, such as full CSS code or bezier curves as the sibling poster put it.

Figma approaches design from an investors point of view.

Like most other web-SaaS tools, they aren't browser based because its better for the user. They sacrifice speed, native functionality, and usability for owning via server-side control over your wallet on a subscription plan.

The startup market in no-longer customer driven. It is investor thesis driven.

That is an odd way to put it if you had read the article. It notes that precisely because Figma was on the web that it was able to have collaboration features, have linkability to specific Figma files, and other such features, and thus serve the customer. As well, I am not sure how they sacrifice speed or usability exactly, when they even use Rust compiled to WASM in order to create the entire UI.

I can concede that SaaS can be, in many cases, be merely investor driven, but I cannot concede that Figma is one of those. Even being investor driven, such as having a subscription business plan, is not bad for the customer per se, as a sustainable business is better than a dead one. Software costs money to make, and more importantly, to upkeep and add features too. I am not sure how you can expect one time fees, especially for enterprise software like Figma is (personal plans are free), in this day and age.

I championed the rollout of Figma at my company and what this article mentions is true: this is a tool for design, not just for designers.

We initially thought we'd need to provision the same number of licenses as we did for Sketch/InVision/Abstract. Turns out way more people started to get involved in the design process and we now have a more inclusive design practice. Content strategists, UX developers, researchers, can all participate early and often. (From a revenue perspective that's a pretty convenient thing for Figma, as each editor costs $45/mo — not only are they eating market shares from the existing pie, but they are also making that pie bigger)

This post encapsulates why Figma is winning, because there are thousands of teams doing this work dealing with the headaches of having design spread across multiple expensive tools. Figma just does it better.

Figma sounds like a great tool, but it feels overhyped to me - especially in this article.

This reads like a long-winded pitch to a Figma investor more than an honest review.

I’ve been wanting to try it out but this article was a little bit of a turn off because it is so enthusiastic. Every tool has strengths and weaknesses so an article like this makes me wonder, what are the trade offs?

Ya but you're probably taking certain things for granted that the author is not. The author thinks Figma really is amazing because it enables what they called "loop stacking" in the article. For programmers this is no big deal, programmers work with dynamic workflows and loops all the time. So if you're a programmer then I can see why you'd think it's overhyped but for most people it really is an amazing tool because it's an improvement over what they're used to.

I'm not a designer so I don't know how good it is and I only skimmed the article but the high level concepts in the article around managing design workflows make sense, e.g.

> Figma solved this problem. Designs in Figma are not just stored in the cloud; they are edited in the cloud, too. This means that Figma users are always working on the same design. With Dropbox, this isn’t true. The files may be stored in the cloud, but the editing happens locally—imagine the difference between sharing Word files in Dropbox vs. editing in Google Docs.

It sounds like Figma reduces friction in the collaboration process by clever use of cloud based and browser coordination. It's not innovative but it's a good application of existing technology to the design space.

Yeah I’m a programmer, so I think you could be right. I’d like to work with our designer using figma and get her thoughts / opinions to get a better understanding.

Also, because I’m a programmer, I’ve lived through many tech hype cycles (with mostly open source and developer tools). So over time I’ve become sensitive to this kind of rhetoric. That’s why my initial reaction was skepticism.

> It sounds like Figma reduces friction in the collaboration process by clever use of cloud based and browser coordination. It's not innovative but it's a good application of existing technology to the design space.

Out of curiosity, what do you consider innovative?

Good question. Do you have a definition we can work with? I tend to focus on theoretical innovations like mathematical theories so my definition is often at odds with what most people think is innovative.

Often innovation is in the eye of the beholder, for a clerk that's been manually entering data for years it might be innovative that it can be replaced with digitalization but for most researchers that's just "implementation" of existing tech.

I don't hold opinions on what the word should mean, just curious to find all the different meanings of it

Innovation is also applying existing concepts in new scenarios.

I'm a developer who has to dip into design files every now and then, so maybe my opinion isn't the most reliable. But I just don't really see a huge difference between Sketch and Figma. The major difference is that you can design online (which is admittedly a very big diff). But the UI itself doesn't really seem to set itself apart that much.

Can anyone here lay out a few major differences that I might be missing?

sketch file is an open format[0]. figma will lock you in. there is no export project feature in figma

https://help.figma.com/hc/en-us/articles/360038006274-Files-...

that is why it is so easy to migrate into figma from sketch, and impossible to migrate away from figma into anything else...

[0] https://github.com/sketch-hq/sketch-file-format

I hate to see another vendor lock in by file format like PSD to keep competitors out.

It better be fixed before they become big enough not to care.

adobe, microsoft, et al. also faked the fix and incorrectly fixed it by exporting into other formats in a broken way. locking in makes sense from a VC point of view.

from my point of view the only way to guarantee is to use software that provides open file formats and develops their features around those open formats. inkscape and sketch seem to be doing this

That's not going to work. People will take features over unknown future uncertainty. Users just have to realize the past mistakes of other companies and pressure the developers to open the format.

"design online" is the key but not so much that the software runs in the browser, more that it allows for a different workflow.

Multiple people can be working on the same thing at the same time and anyone can view the in progress work. This changes the traditional file based workflow where designers pass a file back and forth if they want to keep the work together - often working in a separate file then "merging" the work into a master file one at a time.

Because all the files are online it's possible to see who is working on what including at the very moment. Its really easy for me to get a sense of what other designers are working on and whats been updated recently.

A huge bonus beyond designer collaboration is the way Figma breaks the previous separation of working file and final export. Non-designers can check in on an in-progress file at any time without needing a designer to export some static version of it. This allows designers to work on related things in the same file but each "thing" can be in at various stages of completion without having a negative impact on delivering final work. This is also great for transparency.

At a high level, that's about it, and it is huge. Sketch is macOS only. Hell, this page comes up when you google "sketch for <not macos>": https://www.figma.com/sketch-alternative/

"Sketch is macOS"

I recently came across a Windows-only app called Lunacy which offers Sketch file import and editing for Windows users (I haven't tried the app).

The published Sketch file specification [1] is what allows Figma and Adobe XD (and Lunacy) to import Sketch files. Ironically, neither Figma or Adobe XD publish their file formats.

I think where Figma is pulling ahead of Sketch (in terms of usage behaviour) is that it is being used by more than just designers. In fact, Figma is beginning to encroach (possibly unintentionally) on digital whiteboard tools like Miro and Mural.

[1] https://developer.sketch.com/file-format/

[0] https://www.figma.com/blog/announcing-auto-layout/

[1] https://www.framer.com/

I am not a designer or someone who has tried other design software other than maybe Photoshop, Illustrator.

It is really easy to get up to speed to a workable draft sketch so I suggest you just try it out and see.

Definitely, I'm not affiliated to Sketch but there are a few things on the article that are outdated. Through Sketch Cloud you can actually handle commenting, clickable prototypes and assets for the front-end team (avoiding using Zeplin and Invision). The plugin ecosystem is really strong on Sketch as well, and they are also rolling out collaborative editing this year.

While the things pointed out in the article are true, I think all of those points are actually second to the fact that their engineers are top of the tops. I first learned about Figma from this blog post featured on HN, https://www.figma.com/blog/how-we-built-the-figma-plugin-sys.... I immediately thought how much I'd want to work there if I lived in the area.

The fact that a startup took so much time to build things with intention, the fact that they tried multiple, months-long paths before settling on a solution, and the technical details of their solution were so well thought out - I was incredibly impressed.

My point is you probably could have given the exact same business plan to 99 other companies, but without the engineering talent, and importantly the engineering culture, they would not have been nearly as successful.

Kudos to the whole Figma team, I'm envious of what you've built.

I know and use both Sketch and Figma on a decent level, and I prefer Sketch over Figma. My only complaint to it is that it doesn't have Ubuntu version (I understand why, but still).

To me, is main advantage of Sketch was how many tiny things they got right (before Sketch, I was using Fireworks), and this combined volume of tiny improvements resulted a huge advancement of user experience.

Figma, on the other hand, innovated just one thing: made design online and collaborative. All other tiny niceties are mostly copied. So I prefer to support the guys who crack their heads and innovate.

I also think that Sketch team knows about their main disadvantage, so a web editor for it looks to be in the works.

Not a comment about Figma really, but it has unfortunately become a trigger word for me. These are my observations from working with tech startup companies as a software engineer.

Software solutions will never fix problems that are caused by people.

Sketch, Figma, whatever the next design tool is. Google Docs, Quip, Notion. Trello, Pivotal Tracker, GitHub/ZenHub, Jira. I've gone through tool-switching fatigue with all of the above. Sometimes it doesn't matter much, other times it bogs us down with metawork for months as you figure out which features you gained, and more importantly, lost.

Back to design. I have seen design die the same way every time. Product misuses design resources, effectively making them contractors that hammer out one-off pieces of work. Those pieces of work get nitpicked by some vocal minority holding a lot of clout, until the end result violates the framework that the designer created.

This frustrates everyone over time.

Designers are frustrated because the systems they built are ignored.

Engineers are frustrated because they are adding new debt with every designed feature that has to rebuild parts of the world to make exceptions to systems work.

Product is frustrated because they just don't get why things are slow after they delivered a clear design to the engineers.

Let it all build up and people will start leaving your company.

So yes, use Figma if it suites your company well. If you're reaching for it because your team is frustrated, maybe consider digging into that more before you swap out yet another piece of software for all the wrong reasons.

> Designers are frustrated because the systems they built are ignored.

Designer here. My experience has been that Figma has done the opposite. It's created a lot of consistency with shared component libraries and standardized type / color styles. Also, the fact that engineers can jump into Figma and inspect CSS has been immensely helpful.

In the design world, Figma is like the equivalent of getting a robust IDE with syntax highlighting, code completion, compilation, and debugging. It's replaced multiple tools and connected people in a way that's never been possible.

From the developer perspective I never felt the inspect CSS gets me much over the design documents that I got in the past, that included the systems definitions and rules to follow. To be honest, I prefer the latter and find a lot of the "modern", interactive tools fiddly and ineffective to use (e.g the generated css giving me a html code instead of a variable name even if its a defined design color).

That said, I never felt implementing a design once is the hard part, but keeping them maintained and in sync. What are things that worked for you in that regard? E.g. as an engineer, how do I quicky figure out what I need to adapt when a design has changed? I quickly looked at Figma, and while there is a version history, it just seems to switch completly between versions without anymore detail. So I'm bound to miss changes and completly am reliant on the designer annotating manually.

I love getting figma files as mocks for things i need to implement. I love grabbing CSS from the figma, and I love that the design system allows the designer to not only export CSS, but export it in a way that has annotations (all the colors I get from my designers are annotated with "brand red 300 weight" as a comment, so I can use the right mixin.

Furthermore, I can also, when I'm building out the first-form HTML implementation of the mock, right-click and copy-as-svg the whole component, which makes for a nice stand in while I work on the rest of the code. It is great.

In your experience, do you know if engineers implement the shared component libraries as such in the actual applications? This would be as opposed to engineers directly implementing the end result of work in Figma (Sketch, etc.) that utilizes said components. There is a big difference there, and I'm always curious to have more data points about how this actually happens at other organizations.

Anecdote: at my current org the ideal we talk about is having a component library designed in Figma by the Designers and implemented by the engineers.

In reality Design doesn't use components and most pages end up being composed of a bunch of one-off components and we waste a ton of time.

As a side effect of this, the app design isn't consistent across pages because we aren't sharing components.

Ditto, we have a quite a few designers and they mostly seem to struggle with thinking in components. They use design system like a color guide, and we keep reimplementing patterns on many pages.

Yeah that is the exact result I have observed before as well. I'm really curious to hear more examples about how this actually works out well in the end from others.

I recognize that my view of this is from the bottom up in terms of only really having worked for SV startups, but I want to learn more and see if I can't make it work a bit differently this time.

Some do, sometimes relying on things like Storybook.js to do QA in the middle. There's more and more things to maintain consistency between Figma design and e.g. React components being built.

My uncle had a successful career in advertising. He would always say to me, "don't be just a wrist." He meant participate in guiding the concept and strategy instead of just being an execution person.

I've been in the design industry for 15 years now. When I was starting out, there was a flurry of philosophizing about design. There was a belief that designers should focus on solving problems instead of just making slick UIs. I don't see that discussion anymore. I see a bunch of "wrists" arguing over which pencil is best.

Maybe I'm just an aging curmudgeon...

I was going to say my experience is kind of the opposite — everyone seems to be waxing poetical about "design thinking" but UI work is more and more cut and paste. That being said, the "wrists" may just have moved one abstraction level higher, and they're parroting design thinking tropes (design sprints, etc.) instead of lower level ones.

Good execution compliment good strategy. I think you can also be the valuable wrist that hard to replace.

I've seen people who knows about the theory and have creative idea, but the end result they made is just...lacking?, because they focus just about the strategy part and kinda look down on the importance of good execution. They may know that it is not good, not what they envisioned, but they don't know how to make it better because they don't know how the production process works, and usually have to accept what the vendor gives you.

But well yeah, there are certainly people that just want to be a wrist and not thinking too much about anything.

Anecdotes like this are rarely widely seen, maybe its your companies hiring or your location?

I've had some success in agile-style places pushing for separate story pointing of special-snowflake bullshit design. Like:

"This feature's a 3 if we just do it with native elements or and/or existing UI guidelines, but it's another 5 story on top of that if you really need this ugly crap you're insisting on that'll bloat our bundle by a ton, likely be fragile in a variety of ways, and, realistically, probably have some a11y and cross-platform issues even with a "5" of effort put in."

Suddenly they don't really need it that much, and if they do, well, they have only themselves to blame when "not much" gets done this sprint. Congrats, you just saved them money and (probably) improved the UX and maintainability of the project. Every now and then they'll really insist, which is fine, but if you've got someone who's picking their (let's face it, usually terrible) glittery UI ideas over features & bugfixes more than very occasionally then the project's probably doomed, so at least that becomes clear really fast and you've got numbers to point to if shit gets toxic and the blame-game starts (you did document it, right?)

I thought the Waterfall process was primarily an Agency/Marketing thing, with Tech Startups focusing more on a level playing field where most have input and touch the final product.

This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work, and the better they can show what the final product (and processes) will be like, the better.

Edit: Yes the Waterfall sucks, especially if you're at the bottom.

> This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work

Agreed that it makes sense for contractual work like this, where you just get sign-off, do the work, maybe iterate a little at the end, and then move on to something completely different. In fact, I would say it's the right tool for the job here, despite how much of a charged term "waterfall" has become.

It can easily fall apart when a single company does this enough though, because it usually comes with the lie that it delivers reusable work. You're not, and it manifests itself through your slow, confusingly inconsistent product. Maybe your customers don't care, but nobody will be proud of their work, and you'll start to gain the reputation of "it's buggy and confusing but it works"

The best case I ever found was insisting that designers and developers sit together without much PM interference. The unplanned communication and collaboration ended up producing gold.

That's awesome to hear! Was that something that you had to fight for, and if so, what did that process look like?

My observation with SV startup organizations is that it is very difficult to get that buy-in from product on something like this. These product teams are groups of people trained to believe that "if we deliver X we get $Y", which prioritizes building as many of X in as little time as possible. And I completely agree on that merit, a company SHOULD strive deliver as many revenue generating changes as possible, that's how you avoid death.

If, as an engineer, you challenge that with a push to make better reusable systems and actually stick to them, you will always be met by opposition. "What's the ROI?" they will ask. It's hard to give one because it's not really quantitative, but everyone in the room (generally, product included) KNOWS it's the right move. What do you do?

Are you me? This hits just too close to home.

Work with enough teams and you start to realize the same types of problems come up everywhere :)

this time will be different

This is an interesting opinion. Can you share how would you design a proper structure so the above is not the case?

I have my own "perfect world" solution that I can shed some light on, sure. It's built to address the concerns that I myself have observed, so it might not apply to all. Never just blindly follow the advice of a stranger on the internet :)

Stop wasting time with high fidelity mocks. Engineers shouldn't need a picture perfect rendering of what product wants in order to implement it. The end result almost never ends up being an exact replication anyway for "reasons".

Start doing both of these in parallel: 1. Free up design to build systems that can be used to solve problems. Have them work closely with engineering to ensure the vision will carry ALL the way through to implementation 2. Lean very heavily on low fidelity mocks to hash out the SHAPE of changes to product (inspired by Basecamp https://basecamp.com/shapeup/1.1-chapter-02)

To use object oriented programming as an example, a design system is used in the concrete implementation of the abstract shape of the product requirement. When something doesn't fit into an existing abstraction, you refactor instead of fork.

Amen. I have similar experiences working with designers and PMs and this is my ideal as well.

Designers don’t know the software architectural constraints and what is easy to code up and what is not. Engineers do. PMs know what trade offs they want to make in fidelity for the product, but designers and engineers don’t. What you often end up with is designers spending a lot of time creating designs they think solve the problem, but miss out on a lot of edge cases. They and PM discuss the product design and hand it over to engineers as if their work is done. When the engineer goes to implement it, they find all those edge cases that were missed and the designer has to go and redo a bunch of stuff while engineering is blocked on some of those decisions and PM is concerned why it’s so hard to implement as is.

Our designers use Figma but the licenses are so expensive that people on the product team can’t even make small changes or illustrate concepts. Additionally the UX has tons of hidden features making it hard for non experts to discover how to do simple things like export mockups.

As a result the designers have a backlog of small busy work changes instead of focusing on the key design questions. No one else has licenses to make updates or knows how to use the tool.

The product team has started using Whimsical which is easier to use and is more reasonably priced for people who only use it occasionally or need to quickly illustrate low fidelity concepts. Now we have two design tools to essentially get around UX and pricing problems.

> […] the licenses are so expensive that people on the product team can’t even make small changes or illustrate concepts

I completely agree.

I don't see the Figma files as an output that designers produce. I see it as a product on its own that people should be able to collaborate on.

I'm not going to stop a designer from sending me pull requests. In fact, for small mundane updates I'd LOVE it, since it would take this burden away from me. In fact, our inhouse designers all have GitHub accounts, so in theory they are able to.

But when I want to tweak a little thing in a Figma file, like adjust naming of the symbols, clean up icons, add more diverse examples of the content to document edge cases, or to have grounds for my next discussion with a designer or engineer, I'm not allowed to. Also quite often the thing that I want to do is not necessarily meant for designers, but for my fellow developers. Things like technical notes for implementation.

$45 per month is too expensive?

> the licenses are so expensive that people on the product team can’t even make small changes or illustrate concepts

Licensing models that don’t scale can cause tremendous problems. Early on, design can become a bottleneck. Later, simple changes might be rejected because the cost of redesign is too high. In the worst cases, developers will work ahead of design to meet deadlines (since not every team can afford an expert in the design tool) and the resulting variances will be challenging to reconcile/resolve.

Expensive, high learning curve tools can introduce silos and bottlenecks into an organization.

I love Whimsical. It's just so damn smooth and reliable.

All that being said, I think wanting one tool to serve not just designers but also product teams is probably too high of an expectation. We don't blame developer tooling if designers have a hard time making small updates to demonstrate design concepts. They're different domains, so different tooling is expected.

If Product is editing designs, you have bigger problems than money. And there might be some causality there.

Meh. Everybody knew that "design is not just for designers" for quite a while, Adobe made several failed attempts at "collaboration" workflows trying to solve exactly those kinds of problems. This is just post-hoc justification... and also, let's not jump ahead of ourselves, "Figma wins" is not a foregone conclusion. A few years ago it would've been "why Sketch wins".

Everyone knew cgroups and jails and sandboxes for a long time before Docker happened, still only Docker made these concepts popular for the masses.

That's what I'm saying - if Figma wins (it's still a considerable if) - it's due to great execution, not some grand insight.

I'm not dissing Figma, I'm disagreeing with the article about what makes it great.

I don’t think Figma winning is all that complicated. Designing for the web and mobile is more dynamic now. Designers are expected to show their ideas and produce interactive prototypes. No other design tool has the level of prototype control that Figma does.

Figma is very bad for illustration, but as the industry has killed off any semblance of art or technique this doesn’t matter. What does matter is producing something clickable and animated.

So Figma wins because it’s designed to solve the problem designers have now. Not 10 years ago like Sketch.

Figma is a solid design tool for basic web/mobile apps, however I think that this post reads like a sales pitch more than an honest assessment of the product. The market for design tools is highly competitive, and the 'wins/winner take all' framework does not really apply here. Someone once remarked that every design tool is Photoshop and to a certain degree this is true. Consequently is is easy to clone/transpose the basic functionality/interactions and get teams to switch to a new product. (Think about the recent transition from Sketch to Figma). Companies like Adobe have done well by bundling a suite of complementary products to gain an edge however this is not trivial from a business perspective. Even with bundling the business is not winner take all. Figma is in many ways worse than Sketch, but collaboration is really helpful. That said, it is not that hard to spin up a competitor with React + Firebase in short order.

As much as Figma is in vogue right now, I would rather put money on Notion in the long term. Internal documentation has much higher switching costs than design tools. Notion already has excellent support for Management/Teamwork. They could easily roll out support for prototyping Mobile/Web apps and start eating into Figma's market share.

Figma can be shared with a link and has no version control. Multiple designers can work in the canvass without having to worry if everyone is working form the same version. To me, these were the advantages that got us to switch from Sketch to Figma.

Figma can be shared with a link and has no version control.

This is great for quick, informal design work, like prototyping with participants who aren't specialists.

It's a double-edged sword, though. There are good reasons that professional creative workflows often include revision control and sign-off processes attached to distributing specific revisions outside of the internal team.

Exactly this, since designs are part of requirements, if they can be changed without the knowledge of all involved parties they can become a moving goal post and source of misunderstandings

Our design team has churned off of all prior products and now uses Figma. I've consistently been impressed by the degree to which Figma appears to be completely trouncing InVision / Sketch / others with a superlative product.

The standard trend in enterprise software is towards oligopoly, with a few strong incumbents that struggle to actually kill one another as their products converge over time. Most enterprise businesses focus primarily on sales/marketing as they grow, rather than doubling down on a product that can kill incumbents. The fact that Figma has done both is really impressive and as an enterprise product head definitely something that I admire.

Coincidentally just when "Why Figma Wins" is #1 on HN, the NimConf (#2) is currently about Figma integration in Nim via Fidget:

- https://github.com/treeform/fidget

- https://www.youtube.com/watch?v=IB8Yt2dqZbo&list=PLxLdEZg8DR...

- https://news.ycombinator.com/item?id=23585006

I invested a lot of time a few years back learning to use Sketch and did really like it however half of our office are Windows so on a recent project where I took the lead on design (I'm a software engineer but it's a small team) I decided to use Figma and I was blown away, it was much easier to use than Sketch and I had to do very little Googling on how to achieve what I wanted. I then created the animations, shared it with the head of the team who would be using it, he gave me a few bits of feedback and I then shared it with the rest of my team with no OS related problems at all.

Since I've been on furlough for the last 3 months and working on a new app for myself I jumped back over to Sketch (since I have a licence and have invested in some plugins) and I have to say I do not like it anywhere near as much as Figma, at this point I've only stuck with Sketch because of the extras I have purchased for it, once I feel got my money's worth from them I'll be over to Figma for everything.

I went for a long period of time - after discovering Figma and thinking it was wonderful - of being unable to use it because I could never remember what it was called.

I remember emailing colleagues, googling for "online vector editor" etc.

To be honest I'm not sure it has sunk in even now. I just haven't needed it for a while.

You must have thought it was just a figment of your imagination, eh?

Thats simple - they are cute, reasonably expensive and widely posable, opening many photography options. Their equipment is also largely unterchangeable, so the more you have, the more combinations you can get - often definitely unexpected by their authors. And lastly, they cover most of poular anime and games, so there is a good chance you can get your favorite character in a cute poseable form. :)

Oh, you didn't mean the poseable japanese action figures[0] made by the Good Smile Company ?

[0] https://www.goodsmile.info/en/products/category/figma

Not a Figma user but I took a quick 10 minute look the other day. I have what is probably a dumb question.

Is there any feature to export the designs into some code friendly format? I didn't see one. I only saw export to image.

Maybe that's a good thing? I certainly don't want to bog designers down into the minutia of implementation ... maybe? But it seemed like such a waste to put all the constraints into Figma and then have to manually figure out where they all are and enter them into your UI framework of choice.

I saw the code inspection feature where you can copy and paste values one at a time.

I guess I'm used to automating this stuff as much as possible. The more automation, the more the designer can tweak things to their heart's content in the actual product. Of course I've mostly done games but some games have very complex UIs and if I didn't automate then every day would be the designers asking "move that 3 pixels right", "make that 4 pixels taller", "change the color to #fe83C7" etc...

Note: I get a figma document is full of stuff not intended to make it into the final product. I've always handled that with labeling, naming conventions, etc and I've always setup some flow where the designer can press a button and see their results live in the dev product in a reasonably short amount of time so they can iterate.

Is that something common in app dev?

In 1995, to create web graphics, I learned how to use Adobe Photoshop. It was the first software (along with Notepad) I learned to make websites. In 98 Macromedia Fireworks was released as the first serious tool for creating graphics for the web. I started using it in 1999. It was awesome. It had symbols (a way to use common elements across my designs). I never understood why people continued to use Photoshop which is a photo editing tool to make websites. Adobe bought Macromedia and I used Adobe Fireworks for almost 20 years, even after it was discontinued. I waited a year for Sketch to add symbols. Then I switched from Fireworks to Sketch. I loved Sketch. I was very very happy to use such a lightweight and elegant design tool ... but then Figma came along. I really didn't want to switch from my favourite design tool but last year I understood it is just too amazing to ignore. I switched from Sketch to Figma in a day and now I have a design system.

Can anyone explain why adobe XD's platform isn't dominating the design tools discussion?

They keep improving it with the backing of Adobe (army of devs) and the expertise of creative cloud, along with their community design plugins and remote collab features they just added to the platform. I'm able to quickly mock up designs with ease.

Adobe were caught napping a little. Sketch built a big community of users with a focus on UI design. Neither Photoshop or Illustrator are optimised for these tasks.

Sketch felt nimble and lightweight compared to Adobe's apps to a lot of designers. And it reflected modern designer workflows. The chance to break out of Adobe's embrace probably appealed to many designers too. Adobe realised they had no app to address the 'experience design' process. The result was a new app: Adobe XD.

But XD came late to the game while Sketch's popularity and influence grew. The XD UI has clearly been influenced by Sketch.

The sheer size of Adobe means that XD is being used (it comes as part of Creative Cloud, but it's also free for anyone to use to encourage takeup). But XD doesn't have 'mindshare' among many designers compared to Sketch or Figma.

There is something similar playing out on the iPad. You would think that Adobe would own the digital painting space here. But they don't (at least, not yet) - it's Procreate that illustrators are flocking to use, not Adobe's Fresco which is playing catch-up.

I think you hit the nail on the head why they're not winning - no one wants Creative Cloud.

One issue with using realistic mockups is that reviewers expect the actual product to match. Take the extreme case of Steve Jobs where he would compare Macromedia Director mockups down to the pixel with the actual products and complain if they weren't perfect.

https://books.google.com/books?id=390ISyA-CUEC&pg=PA49&lpg=P...

Interesting opinions. But mostly opinions, not backed by any data. Those features that the author considers to be "winning bets", might not be winners at all. Actually some of them may be considered Figma's downsides and maybe it would grow faster having had done things differently..

It all may be down to being relatively reliable (not that common among design & prototyping tools) and keeping the right balance between adding some slightly advanced prototyping features and still keeping it overall rather simple. Obviously I don't know the truth. Just saying it might be just that, and people are happy with it despite being browser based and without anybody really needing collaborative designing..

Figma is a great piece of engineering, but I'm sticking with Sketch for personal use since it checks all of my boxes.

I've been watching it though, because I'm curious to see if they'll ever switch away from Electron for their desktop app. As far as I can tell, it doesn't need much from the browser other than a canvas. A lightweight standalone webassembly+canvas runtime would probably be enough to run it with some tweaks and could net significant performance/efficiency improvements (especially if said runtime leveraged Vulkan, Metal, etc). If they do that, it'll grab my attention and may kick off a new way to build cross-platform high-performance desktop apps.

Just curious to know what those boxes are that Sketch checks for you.

Right now, Sketch seems to be the prevailing product in the overall design community. But in my opinion it's only because it was the first to really get such a strong hold on its niche, and a new product will take its place at the top soon.

What turns me off to it as a person who missed its initial spread is that the vanilla Sketch experience leaves a lot to be desired. It's cool that it supports plugins to extend its functionality, but I don't like how it's expected that you just have to get a bunch of plugins to reach parity with the vanilla features of its competitors. (The Mac only support is also a negative too, but it's not that big of a deal for me.)

I don't use many plugins. I mostly just need a reasonably capable, digital-first vector canvas to work on, and Sketch does that very well.

It also helps that it's pretty easy on resources — when I first picked it up, my daily driver was a Core 2 Duo MacBook with 4GB of RAM, so back then efficiency was very important. These days I have access to much more powerful machines, but it's still nice that it can sit in the background with large projects open without impacting a browser with dozens of open tabs and mammoth apps like Xcode and Android studio.

So for now, there's just not enough to gain from investing time and effort into moving over to Figma.

Everything in this article makes sense to me. But sadly, I don’t know how useful it is to the aspiring founders who are trying to build a product right now. It’s relatively straightforward to see Figma’s success depended on these reasons but what will drive the success of the products that are getting built from scratch right now? I would love to see someone point out technical decision like “browser-first experience” but in 2020 version that’s fundamentally different from what everyone else is doing but will make sense in 2025 in retrospect.

My main issue with Adobe XD and I believe this is an issue with Figma as well is the fact that there is no versioning on shared designs. We found ourselves in this situation with Adobe XD a few times where the designs were delivered to the developer and after part of the implementation was done the designer pushed changes which made the implementation look as if it was no longer following the approved UI. I looked at Figma as an alternative but it seems to have the same issue unless this has changed. Can anyone confirm?

I share different screens and version them.

That leaves versioning on designers side which means designer is the only one who can confirm the changes. This can lead to misunderstandings.

unclear what you mean by "designer is the only one who can confirm the changes".

hopefully, I would assume there will be additional documentation that refers to a certain version that is approved

---

> That leaves versioning on designers side

how was versioning the designs prior to Figma? whose responsibility was it?

I'm mostly a front end dev and previously I jumped directly into code and implemented whatever I had in mind without any clear direction (which should not have been the case at all). But after hearing about Figma, I first created a mockup of what I had in mind and just straight up designed for 2-3 days till I was satisfied and then dove into code.

Needless to say, it was a game changer as it increased my productivity as I had a clear goal in mind. I'm never going to delve straight into code w/o a clear design henceforth.

Figma is great. The single biggest feature from figma is that it's shared/collaboration oriented by default. This is due to its online nature (compared to installable apps such as sketch, incision and xd).

Not all designers like this, but I love how figma makes work available across design teams, and how components becomes easily usable. I discovered my colleagues work by accident all the time.

Now, all this creates other problems, obviously: now designers also need to maintain interdependent assets just like software dependencies.

Could any designers here explain why they use Figma instead of Invision?

I used Invision before and loved it (as a developer) for collaborating on creating mockups and putting them into reality.

Now working with a team that uses Figma and helping them create prototypes is...painful. It seems great for creating the design itself but prototyping has been way harder with it than in Invision. I'm wondering if maybe we're just unfamiliar with the right way to use that part of the tool.

InVision doesn't have any design features. It's just a prototyping tool, you need to import designs from somewhere.

Figma is a bit like Sketch+InVision combined. With the InVision part actually better than InVision.

There is also InVision Studio, which was their attempt on full-fledged prototyping tool, but it's largely abandoned now, always suffered with huge reliability and perfomance issues and never became truly usable tool. It's a pity, it looked very promising.

I've been sketching, prototyping and designing UI for years and I just don't get Figma. It's just baffles me that people would work on this level of granularity (let's draw everything from scratch) instead of working with UI elements like buttons, text fields, etc. I feel like I'm missing something very fundamentally about Figma because every time I've used it I leave confused and frustrated.

InVision has its share of problems.

I'm disappointed in the lack of ability to easily control vectors using the alt key that all the other programs have

plugins are rather lacking, wish they had more plugins in their library.

design to code would routinely lop off things like gradients

lacking in feature parity with figma, sketch <- strong point

Animation features are def a strong point but these and a few other gripes are why I use Figma.

You know why it won for me? It had a Windows version from the start, so our team (Mac/Win) could actually get work done, since most other tools are Mac only.

My concerns with these cloud only solutions is that you lose control and you are locked in. See what happened to creatives in Venezuela when Adobe had to cut off access because of some trade sanctions.

If you're a freelancer I'd rather use native apps that have a perpetual license, like the Affinity apps.

If you're part of a bigger team and need collaboration features or easier hand off to engineering teams then yes I think Figma is great.

All design tools lack the ability to design the most important part of an UI: state. I think Figma is an awesome tool for making good looking mockups, but as a tool for describing how the UI will actually work, it has the same flaws as all other tools for this. Storybooks are great but there is still need for endless discussions when converting fancy Figma designs to actual interactive components with state

It depends on what you call "design". User flow, interactions, states, rectangles and colors or just rectangles and colors. If first, there are a lot of other tools, maybe not so hyped so you don't see them every day. Just to name a few: Axure, Justinmind, iRise, Indigo Design. Recent version of Adobe XD is quite a powerful tool as well. With the rise of rapid application development tools we possibly can add Bubble, Retool, Outsystems and similar tools to this list too.

Love Figma!

However, their enterprise licence is $45/month ($540 annually)! That is ludicrous for the functionality that the app provides.

In comparison Microsoft or Adobe software (Photoshop is $250/annum) has immense amount of technology & man month behind - Photoshop has been in development since 1990, and Microsoft Office must be in development for similar amount of period and have perhaps 5K+ employees (wild guess).

I used Figma at my last gig and while some of it is really nice, I found the productivity sub-par compared to even Sketch which I don't like very much. It seems that every new generation of design tools does less than the one before and is less productive while delivering gains in areas that are at best a nice to have. I'm scratching my head in this regard.

As a programmer I used to take the ability to manage my workflows as I saw fit for granted. It is amazing how much value there is in providing some level of programming capabilities to the average user. This post is essentially describing a workflow management system for designers. It's amazing Figma has unlocked so much value.

Does anyone actually like using Figma? Honest question. I’ve use it for collaboration a few times but found it painful. I’d much rather have used Photoshop and screen sharing if given the choice. I understand that this solution doesn’t scale though.

I like being able to combine drawing+prototyping in one place, with an easy way of sharing. Syncing from Sketch to InVision is still not great and prototyping in InVision is actually very limited and not exactly a pleasure to use either.

Not in a hundred years could I imagine going back to Photoshop for doing product design. Figma is a joy to use. Photoshop is a slow, clunky thing of the past in this particular field of design.

Interesting, to me Figma is dog slow, feature poor… I can’t imagine why people would use it.

The problem that I have with Figma is that it just doesn't work at all when you don't have an internet connectivity. At least with Sketch you can keep working when you want to work outside in the park and you ran out of hot spot data.

Interesting. I have a 2017 MBP, 16GB, 2.9 GHZ quad-core, and Figma feels terribly slow.

I briefly had Figma, Zoom, and Slack (three workspaces) open at once on Friday on my Mac. My computer was more or less unusable and sounded very sorry for itself; it was sort of entertaining, baffling, and sad all at the same time.

I ended up quitting Slack and asking the designer if she could show us the Figma stuff over screenshare on Zoom instead. Obviously multi-tasking is too much to expect these days.

Comparing pricing directly, looks like Sketch is cheaper, if company already uses Macs. But how does it compare in reality? Do developers need additional Figma licences, or can designers just share designs with them to inspect?

Pure “viewer” licenses are free on figma. You only pay per editor.

And IMHO the price delta between sketch and figma is basically a rounding error on the wage cost of your designers, so it’s barely even worth thinking about.

We used Figma to design our app[1] (and everything around the app), and real-time collaboration was truly invaluable as a fully remote team.

[1] https://supernotes.app

Figma users: can it export CSS grid? Would love to start using autogenerated HTML/CSS but don't want to go back to 'display: block' and the hacks that invariably come with it.

I think the terminal output is the figma viewer. I have a hard time seeing the point of the role and software if a front end developer has to hand translate the design to actual code or styling.

It wins because it works and it continues to release useful features.

I wish Figma would add page formatting and links so that it could be used as a wiki also. Figma is on a much better track to make a good product than Notion.

Fun fact: Figma recently announced link/URL support

I totally agree and have been moving my spec work from Notion to Figma too!

At a high level, how are you spec'ing in Figma?

I am really liking the figma integration in wiki for architecture diagrams and graphs. The dynamic auto update.

That sounds a lot like https://www.axure.com/ which was quite popular 10 years ago.

Axure beats Figma when it comes to wireframing and prototyping.

Building enterprise apps means dealing with a lot of forms and grids and making these fully interactive is easier in Axure.

I think many people don't get why Axure is still popular is because they don't design for enterprise software. Sometimes it is just much easier to create table as a table and not as a bunch of vertical and horizontal lines like you will have to do in most of design software.

Figma does not seem to tie into the OS UI primitives.

What is the experience for visually-impaired users that need high contrast UIs or braille terminals?

Figma didn’t “fix” design collaboration, it just made it easier. If your org has poor design maturity then the tool doesn’t matter.

What's the best stack/methods to take a properly designed Figma prototype into a HTML5+CSS+maybe JS web app? (PWA)

I keep thinking of the anime figure line Figma whenever someone says Figma :V

I do not work on a Mac or want to. So anything that praises Figma over Sketch I upvote. You might think that it's a shallow position but when a company decides to limit their product to only one platform there is a price they have to pay.

That's because 99% of good designers are on Mac. That has never been a serious problem.

Also Figma is working on Windows.

Reply on news.ycombinator.com