Earlier quoted context omitted.
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
Why Figma Wins
81–90 of 191 posts
Re: Why Figma Wins
#82Does 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.
Re: Why Figma Wins
#83Figma 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?
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?
"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.
Re: Why Figma Wins
#84Earlier quoted context omitted.
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.
Re: Why Figma Wins
#85We 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…
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.
> Engineers are talking to designers.
We really do love to pump ourselves up, don't we? My grandpa was an engineer who built bridges. I wouldn't dare call myself an "engineer" for slicing up a design, authoring markup and CSS, and sprinkling in a JS plugin or two.
Re: Why Figma Wins
#86We 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…
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 l…
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.
Re: Why Figma Wins
#87We 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…
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.
Re: Why Figma Wins
#88We 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…
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 l…
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.
Re: Why Figma Wins
#89Earlier quoted context omitted.
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 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.
Re: Why Figma Wins
#90Not 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 al…
> 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…
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.