61–70 of 191 posts
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 al…
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?
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?
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...
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 al…
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 t…
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"
- https://github.com/treeform/fidget
- https://www.youtube.com/watch?v=IB8Yt2dqZbo&list=PLxLdEZg8DR...
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 al…
Are you me? This hits just too close to home.
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…
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.
I'm not dissing Figma, I'm disagreeing with the article about what makes it great.
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?
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.
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 al…
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.
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?