Will Figma become an awkward middle ground?

Major bias disclaimer:

1. I work for Figma

2. I work on AI at Figma, as well as on the design systems part of the product

3. Prior to Figma, I spent 7 years as a prototyper teaching designers how to go from idea->code without a design step in between

I love designing in code, and I HIGHLY recommend you do so for smaller projects, but I disagree with some of the assumptions the author is making. The author states, "The reason Figma has over 4 million users is because it takes most people too long to code their designs", which I feel is inaccurate. For less-experienced creators, it's mainly because the UX is more approachable in a design tool. That's less relevant here since the author is talking about designers who can code. For the most experienced designers, it's more about alignment.

As an example, most of my side project[1] was designed entirely in code... until it got to a certain scale. Designing in code was amazing early on when every page could be a new pattern. After a while, managing variations of components and ensuring that I wasn't diverging from existing patterns became non-trivial. Things became even harder when I hired another person to work on things. At that point, alignment became crucial. We needed to ensure that designs we were both working on were aligned with each other. Patterns one created needed to be reused, not reinvented by the other. This is something that's very hard to do in code. I ended up creating a mirror of the existing implementation of the site in Figma from scratch. For the iOS app, I ended up starting it in Figma[2] so we could easily compare implementations and land on an agreed pattern. Alignment with patterns and with the team was the #1 reason why we operated in a design tool during this time.

[1] https://non.io

[2] https://www.figma.com/design/im8a7L7axmbj0S0lm27NKa/Nonio-iO...

Getting designers willing to setup their workstation to hand code a React app with dozens of dependencies and be constrained by the DOM is not going to go very well. And then doing it all over again with several other web libraries/languages. This is not even design, it's a developer role who just happens to paint UI with code.

I think the assumption here is that once you make a component library in code, you can just map low-fidelity wireframe components (from something like Balsamiq) onto those "real" components, and go from a napkin sketch to a functioning website without the awkward middle ground of vector designs and clickable slideshow prototypes.

It's an interesting idea. I'm skeptical that, in the real world, you can reliably infer everything you need to produce code from a simple wireframe: how do you deal with specific interactions, specific data, specific operations on that data? Balsamiq-style mockups are all about not getting specific, in order to keep the fidelity low and the velocity high.

In practice, with Figma, the thing I've noticed is that I use low-fidelity wireframes less than in the past, because it's just as easy and fast to use high-fidelity components from my design library. If I'm just stacking Lego blocks together to make a UI, why would I use low-fidelity blocks, if I already have high-fidelity blocks that are much less ambiguous?

In other words, I'm not sure Figma is in the middle ground between sketches and code anymore, I think it's just as easy to think of it as a brainstorming tool that happens to produce high-fidelity results if you use it right.

This has always been the case. Zero to one with a single developer or a very small team is the most exciting part of the lifecycle of a project. Medium to large size companies have very different challenges.

Hard disagree here. Are you writing production code, or are you building mockups/prototypes?

I don't want non software engineers touching production code. It's too hard, and the depth of skillset for a product/UX designer is already huge.

If you find css and js faster for prototyping and mockups, then sure. I'm doubtful and still yet to see that work in the wild.