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.
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.
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 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.
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.
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'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.
"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?)
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.
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"
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?
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.
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.
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.