Hacker News new | ask | show | jobs
by jjcm 702 days ago
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...

1 comments

When you say that reusing patterns and components is very hard to do in code, do you mean this applies even when building a reference page in code, with your design system and all of your components?
The problem stems mainly from this statement:

> with your design system and all of your components

While this is straightforward to do, it doesn't encapsulate all of your patterns. No design system should. Design systems should capture the top 90% most-reused patterns, but there will always be patterns that live outside of that. Being able to visually see those, copy them, and tweak them in a context multiple team members can give feedback on is immensely valuable.