No Figma, I Won't Fit in Your Little Box
Posted3 months agoActive3 months ago
blog.nordcraft.comTechstory
heatednegative
Debate
80/100
FigmaDesign ToolsProductivity
Key topics
Figma
Design Tools
Productivity
The author criticizes Figma's limitations and argues that it constrains creativity, sparking a debate among commenters about design tool trade-offs and the importance of flexibility.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
4h
Peak period
37
0-12h
Avg / period
12.5
Comment distribution75 data points
Loading chart...
Based on 75 loaded comments
Key moments
- 01Story posted
Oct 1, 2025 at 8:50 AM EDT
3 months ago
Step 01 - 02First comment
Oct 1, 2025 at 12:33 PM EDT
4h after posting
Step 02 - 03Peak activity
37 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 7, 2025 at 11:26 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45437081Type: storyLast synced: 11/20/2025, 2:49:46 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
"We don't like Figma. We don't like designers and developers being split. So we built and are selling.... Another tool for mocking UI designs"?
I don't know about this startup's product but based on their homepage having (real) HTML/CSS output as a core part of the creation process would have helped me many times. Designers need to be constrained.
Expecting designers to know how to build production websites in html/css/js before designing is apparently a step people skip over these days. It creates meaningless design and dev cycles + tons of extra approval meetings by marketing/execs.
I guess one could create a really good tool where UI designers make a real web reusable pattern language, and UX designers specialize them into a set of templates the software developers can actually apply.
Figma isn't a web app in the traditional sense of the word, it's a C++ app with a WebAssembly compile target. https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
E.g., it's more similar to how Adobe Illustrator and other C++ graphics programs render content than it is how a web browser engine renders HTML and CSS.
I.e., "Tool A, used to design for technology B, doesn't output files in technology B format. [...] doesn't make much sense".
E.g., why not just use Webflow then? From my understanding, that's what it does, that's what it's made for.
I’d argue Figma got where they are mainly by streamlining the handoff process, not because of their live editing collaboration features per se. But there isn’t really an empirical way to validate this. But my point is really if you want to export natively to the web, just use, promote, etc... WebFlow that's the tool designed for that job.
> [Figma targets] design more broadly than simply website building.
This is absolutely true, but I’d argue it’s impossible to be able to both target many platforms, and simultaneously be able to export to all those platforms natively. I.e., you have to build the constraints of a specific platform into your tool in order to export to that format. This is what WebFlow is (and using it for just 5 minutes makes clear the trade-offs of designing a tool like that).
I think they could do more for exports in this day and age, but I'm not them.
> people got in the trouble of making a web-app [...] and those designs are not plain web pages.
I will definitely be checking Nordcraft out.
It is a very different tool than Figma. In Nordcraft designers and developers work together in the same tool.
This was never the case and in fact a rewriting of history. My first "proper" job in web development was taking a PSD from a designer and turning that into a XHTML template. Quite a lot of the time the designs looked nice in Photoshop but were almost impossible to implement (at least in CSS 2).
I've worked in several since then and most were using Photoshop to create designs or design guidelines to pass over the developers. I used to "cut up the design" and then implement into XHTML template and controls. This was pretty much the norm everywhere if the company cared about how the website / webapp looked.
There were some frontend designer types that would write code, but I've met actually two of them during my career as a dev that was heavily front-end focused until 2023.
And of course that abomination of a HTML tag still works:
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I was procedural programmer (came from Sysadmin - shell and perl) and I had zero desire to learn the whole timeline approach to actions (my memory is fuzzy) but I would give them endpoints to call server side!
In fact, I stopped coding as a job when it became expected that I would do back end database & business logic stuff AND fiddle with front-end code to make it work/look the same in 3 very different browsers, and update the code each time (I'm looking at you Microsoft) a browser vendor would do something stoopid.
Running things on AWS is just foolish IMO. You data is locked and infra is locked into their platform.
Sometimes there would be more interaction to have the code output things in a form more amenable to the desired design, but a lot of the time it was really that simple - the designers worked in CSS and the exchange format was divs with well-defined classes. You can do a lot with a workflow that simple.
I imagine it's a bit harder if you're using a modern stack where your code is separated from what's actually rendered to the user by a dozen layers, but designers are quite capable of working with CSS rather than Photoshop.
So someone wrote a bunch of server code (backend) and then handed off for someone to style the frontend. This is what happens now in most teams. The person styling the frontend was never referred to as a "designer".
> Sometimes there would be more interaction to have the code output things in a form more amenable to the desired design, but a lot of the time it was really that simple - the designers worked in CSS and the exchange format was divs with well-defined classes. You can do a lot with a workflow that simple.
I am aware. However that isn't the norm in most places. What happens is that the best dev that can style stuff is lumbered with doing all the frontend work and most of their colleagues don't understand it.
Larger orgs have dedicated frontend/backend teams.
> I imagine it's a bit harder if you're using a modern stack where your code is separated from what's actually rendered to the user by a dozen layers, but designers are quite capable of working with CSS rather than Photoshop.
This are actually simpler than they were back then and there is better separate between the frontend and backend. So it actually easier IMO.
The term frontend developer didn't really exists back then because allmost all the logic code was on the server.
I have worked in large corps and smaller agencies as a full stack / front-end dev for about 18 years.
This wasn't just the case in my part of the world. There were prominent online publication that were extolling the virtues of designers embracing creating their designs in CSS and HTML and moving away from using Photoshop.
First you say that you have never herd of designers working with HTML and CSS and then you say that prominent online publications were advertising it?
- Designers were not working with HTML and CSS (this was about ~2008-2011). I met one "designer" who would do HTML and CSS back in about 2015. I met another woman that could do it in 2022. I've worked in a bunch of web agencies and corps.
- Some designers due to emergence of smart phones had started experimenting with using HTML 5 and CSS 3 to create responsive designed.
- There were articles in online publications and blogs where people were extolling the virtues of it, trying to convince others.
- This ultimately didn't happen. People are still using Photoshop if they are not using Figma. You have dedicated front-end devs and/or teams in most orgs if they actually care about the UX/UI quality. Otherwise they just just use a bootstrap/tailwind theme and call it a day.
I stopped doing frontend dev primarily back in 2023 after I realised I was still fixing the same stupid iOS bugs from a decade before hand.
I don't really understand why you first claim that designers absolutely were not writing CSS and then go onto admitting that they even wrote articles about why everyone should.
That is a very clear contradiction. Clearly a lot of designers were writing CSS otherwise they wouldn't write about it...
I really don't know what to say with this statement. Obviously there were very few doing so, and trying to evangelise others into doing so. I think I made that crystal clear.
It seems you are getting hung up on the difference between "I've encountered this very rarely" and "none". If that is your complaint you are simply nitpicking. Which is what I suspect you are doing.
> That is a very clear contradiction. Clearly a lot of designers were writing CSS otherwise they wouldn't write about it...
No you cannot draw that conclusion. If there were already at the time "a lot" they wouldn't need to try to evangelise others to do so would they? There is no contradiction at all. Again this feels like you are angling for something that not there.
TBH from my interactions with you so far, It feels like you're wilfully misinterpreting my statements for gotcha. So I would rather we would leave it there.
I love Figma’s dev mode. Saves me and the designer time from measuring sizes and eyedropping colors. Figma also allows me to export assets myself instead of waiting for the designer to do it, or do it myself poorly from Photoshop.
The relationship between design and dev is much more collaborative now. It was downright hostile pre-Figma with photoshop and illustrator files. Nevermind versioning, sharing and comments…
I wasn't arguing that the handoff was ever good. I was saying when the person designing the UI also wrote the CSS you didn't need a handoff
This was absolutely the norm at a lot of companies. It was very normal for the developers to work in either PHP or Ruby on Rails and the designers wrote CSS.
It is also true that since the introduction of modern frameworks we see significantly fewer designers who know CSS.
> It is also true that since the introduction of modern frameworks we see significantly fewer designers who know CSS.
None of these people knew CSS at all. I am talking pre-2012. Bootstrap version 1 or 2 was out at the time and 960 grid css was only out a few years before.
I had to do work in Photoshop (or usually Macromedia Fireworks), and then code it up in Cold Fusion.
> Designers would go into a design team and draw user interfaces. Developers would go into a dev team and write code. And thus, the hand-off was born.
Which is exactly what Figma solves and why it's so valuable.
Figma is the place where the UX team and dev team meet and discuss, specify design and behavior together through back and forth, and helps the dev team move from there with exactly what they need.
Nordcraft might want to be the next Figma, as it's apparently a lucrative position provided you execute incredibly and capture most of the market. But how they describe it they're not properly assessing or representing any of the current reality.
I kinda wonder what it would need to achieve to be significantly different from Figma. Perhaps if it was actually a whole production runtime where designers define front layers and the dev team codes binds them to a backend ? Basically a WordPress competitor ?
I find many Figma designs basically force you to use fancy JS to assemble their UI designs. I know everyone uses React these days but you really shouldn't have to constantly write JS just to reproduce what's in a UI design. It creates so much needless dev and browser overhead.
The excessively fancy UI issue can be avoided if the devs enter the process at the prototyping phase. And Figma can be used for that: start with a wirefame and get everyone's input, comments, or even let the devs make counterpropositions (basically MRs?) by tweaking a copy of whatever screens are worked on. And as the design gets closer to reality the back and forth can continue in Figma.
That requires team collaboration and the willingness to build decent HTML/CSS in the first place, none of which are a given, but for teams working at that level it's a boon.
If figma was built on top of HTML and CSS—and so couldn’t represent designs that HTML and CSS can’t, this might be less of an issue.
Granted it would still be a problem because there are always underlying technical and processes issues that should be uncovered before you leave the wireframe phase that have nothing to do with HTML and CSS.
> the designer and management has already fallen in love with what appears to be a final product.
This is probably the crux of the issue. It's the same process as asking a famous illustrator to draw a cool house, and then ask some random architect to make it a reality. I'm always amazed at people doing so, that's not the type of house I'd like to live in.
The problem here is that designers are limited by their tools. Figma can only do 10% of what CSS is capable of.
We can try to work around those issues with closer collaboration early on, but the truth is that most of the problems aren't universal. They are constructed
But ignoring those fixable processes and hiring issues, there is plenty to be said about the new world of isolated islands of UI/UX designers, frontend, backend teams. I blame Javascript/React eating the world more than Figma. React/Vue opened up a whole hyper complex world of UI design and shit rolls downhill from UI->frontend->backend->users (mostly via performance/complexity).
Nordcraft is a completely different type of tool. It is based on HTML and CSS instead of layers and absolute positioning.
... did this person just start in the industry like three years ago?
It used to be completely normal for companies to have developers who worked in php or ruby on rails and have designers take care of the css.
You are absolutely right that in the early days many UI designers came from graphic design and worked in photoshop. But the fact that they also existed in some companies isn't really relevant.
If you want to get into the shortcomings of Figma when it comes to hand off, I'm more than happy to have that conversation. Units that aren't valid in the CSS spec? Sure. Vector tools leading to things that are only achievable through clip path and masking? You bet. But claiming that designers and developers should have the same job when they're completely different skill sets and claiming that both roles are using the wrong tools to get the job done is no way to sell your product.
It is on our LinkedIn profile
Time for what? To click the "open app" button? Okay, so I clicked.
It doesn't open app. A button labelled "open app" should do what's on the tin. Instead it prompts for sign-up with terms and conditions warnings. I'm out.
Just open the app without sign-in! Why not? Too hard? Too scary? You can haggle for sign-up later. Let's see what you have right now, under the button labelled with a promise that I expect you to keep. Lying to me on page one is not a good start.
Here's an example of a web app that does it right. The button "start using Photopea" isn't a lie: https://www.photopea.com/
Eventually all roads led to Figma somehow, which honestly I would've never expected. Still surprised Figma became Sketch before Sketch could become Figma.
The solution is to get rid of the design handoff all together. Instead of designing user interfaces in vector drawing tools we need web design tools.
If you are just one tool are not going to have meainingful change.
What you really mean is that you’re looking into how you can open source just enough to create a free-to-paid entrapment pathway. You’ll do open source if you can provide a product where all of your users eventually hit a wall and need to upgrade to a paid plan.
A more honest answer from you would have been “we are just looking to provide a solution” rather than pretending to be working on a true open tooling ecosystem.
Don’t pretend to be open source as in Linux or git when you’re really open source as in MongoDB or Chef Software.