I used it today to take a look at my previously built design system with Logos, branding, fonts, and everything else. After a lot of annoying tweaking back and forth, finally, I got something that was satisfactory.
Then I looked at the usage and it said I had used 95% of my Claude design usage for the week!
This isn't a real tool. This is a plaything, if that's what they're providing as examples.
I used Claude Design to see how it'd spit out a design I already had been working on for some weeks, given a dense enough prompt and a decent requirements document (I did not feed it visuals). I thought the output was pretty good! It didn't match the style we're after at all but it did do some logical content grouping and made some IA decisions I decided to pull into my own explorations. Overall I left with a good impression.
And then I was scrolling Twitter, and saw someone else post their own "success story" and the design was nearly identical to the mock up Claude Design made for me. Lol. The homogenization problem will continue to plague tools like these to some degree, much in the same way AI generated text or code or imagery has a sort of homogenous tone or feel to it.
That’s because designers stopped caring about following each platform’s guidelines because they want to spread “brand recognition” or some shit like that.
This is kind of a revisionist view of software. I think most of the consistency we remember from software past is because skipping the OS tollboxes and doing your own custom UI was hard rather than because most software developers cared about consistency. Yes the OS vendors did, but one doesn't need to go far to find applications that very much did their own thing. "Bubbly" and "goopy" UIs of the sort "Kai's Power Tools" exemplified were all over in the 90's. Everyone's favorite Winamp was famously not using the standard UI toolkits and had a heavily customizable UI. To say nothing of the many software packages that used the standard toolkits only far enough to give you a window that was then filled with some sort of Macromedia or similar UI that was then completely proprietary to the application itself (think encyclopedia and other educational software of the day). Even the OS vendors couldn't help themselves sometimes (looking at you QuickTime 7)
If older software was more consistent, it's only because the OS didn't provide nearly the same degree of customization options that HTML and CSS provide developers today. Not because of some pride in consistency.
This exudes everywhere. I've had cases of where some weirdo company changes their packaging on, say, soap... and now I literally can't find what I used to use. The logic is that some other company is cloning their look, so they want to "stand out" again, and thus change theirs.
Sometimes, I'll manage to find the brand with the new colours and logo. But often even then, I can't find the specific product from that brand. They've changed it so much I can't tell which version I picked before. Which makes me look for something more like what I used to have.
Good job "standing out" guys. I'd say literally maybe 1/3 of the time, I've just literally lost products. I don't know the name, just how it looks.
Distinctive hammers and other tools get brand recognition and free marketing out in the field, ostensibly increasing sales - that's why all the tool companies have their distinct colors and you can see the type of tool someone uses from a distance. Matching chargers/batteries incompatible with other brands perpetuate this even further.
Someone IS designing all this, they just aren't optimizing for what you wish they were.
Design is too broad a word for what is being discussed here and often in the world at large.
Still, to me, good design is intuitive. I look at the thing, and I know how to use it. If it looks great and distinctive, even better. But most outlandishly distinctive design I've (consciously?) found is terrible.
Obviously, these short sentences hide a lot:
- To know how to use things, I must have prior experience. But different users have different prior experiences and acquired design patterns (i.e. interaction patterns)
- My knowledge of the domain is also different from that of other users.
- The way I interact with the system is affected by many factors (e.g. accessibility related concerns, zoom, etc.)
- Intuition is not magic. It comes after training as well. Good design is discoverable. Extraordinary design reinforces its own patterns seamlessly, so that I learn it without even knowing I'm learning (see: hidden tutorials in game design). I also include here the incredible attributes of good design that far predate computer-related design (e.g. how an icon should be recognizable just by its silhouette, or how apps "invisibly" teach us what each color or even section of the screen means).
- My incentive to learn (sometimes "tolerate") the design depends on many variables. Some of these include the design's "taste", yes. Others depend on how much my boss/client is paying me to "use this shit".
I wouldn't say I want a world where everything looks the same, but I certainly want one where everything works the same, and some geniuses once in a while add something new to my list of known (and loved) design patterns. I am not anti-design-experiments, but I will take a predictable UI that looks like windows 98 everyday over some "distinctive" shit that breaks all manner of expected behaviors (from keyboard shortcuts, to colors, to button placement, to relative sizing, to........)
I would take every news site delivering straight text, and letting me pick the page layout template to apply to all of them. Some kind of markup language that could be transmitted and then respect the users preferences as far as rendering.
I think its good that HN and reddit are basically the same, or that all old forums were basically the same but with different color schemes. Homogeneity is a blessing for UX.
Honestly, HN and Reddit are almost as different as threaded discussion forums are possible to be, especially New Reddit with it's "click hundreds of times to unhide most of the text on this page" approach to threading. Reddit's overall design aesthetic is all about pictures and headings and sidebars, and even minor details like the up/down arrows look different and are placed in a different relative position. The only design element they've got in common is Verdana, and that simply because when the websites were launched you only had two widely-installed sans-serif fonts to choose from...
It’s really difficult to make a design that is usable, follows platform standards, yet has unique personality.
I mean, really difficult.
Coming up with a design that relies exclusively on platform standards is easy, “low-hanging fruit.”
I write stuff for iOS/MacOS/WatchOS. There’s tremendous pressure to follow platform standards. In fact, if you use SwiftUI, it’s very hard to deviate from them. SwiftUI makes it easy (crazy easy) to follow the herd, and downright miserable, if you want to blaze your own trail.
90% of the time, that’s actually a good thing. I get pretty sick of designers that refuse to compromise, and believe that their graphic opus is more important than usable UI. It’s even worse, if the designer is an engineer, with little background in graphic design.
A designer that knows how to compromise, and work with usability, is a unicorn. If you have one, keep them.
Like the code that LLMs produce, I expect the designs to be fairly low-effort, but that will be a good thing, overall. They will be effective and usable. We need more of that.
> I used it today to take a look at my previously built design system with Logos, branding, fonts, and everything else.
The fact that you are using this language tells me you are probably more advanced than the average individual, and likely have higher expectations.
My sister-in-law has a small apparel company. She’s developed quite a bit of skill over the past six years but she really struggled at the start. She had great ideas, but translating them to something she could apply was frustrating. *Anything* that could have helped her there would have been worth a look.
> The fact that you are using this language tells me you are probably more advanced than the average individual, and likely have higher expectations.
I am terrible at frontend, but I’m a decent engineer, and I needed to do frontend with AI a few weeks ago. The first thing I did is figure out how other people manage this; apparently there’s a whole design system made of atoms, molecules and organisms that works well.
I asked Claude about this, set up a workflow together, and now I have a design system markdown, maintaining the design standards using the atoms etc vocabulary, and it works really well.
If I can pick this up in a few days, most people that are serious about design are able to as well.
Funny. My read on that language was this person has absolutely no idea what a truly robust and scalable design system and component library actually are, particularly within the scope of a successful business. Well built ones serve every facet of the organization, not just the product.
I had a similar experience with running out of usage quite quickly, after setting up one design system properly, and then getting pretty close with a second one. But it's a research preview - I'm sure it will change.
I was quite happy with what I pulled off using the first design system: I wanted a new footer section for my IPAAS startup, it generated four options, the fourth of which was quite good. We iterated on it for a bit, then I pulled it into Claude Code (that integrated feature is very cool), CC built it, I deployed it, done. (Bottom section of https://tediware.com/ if you're interested, the bit with "Origin story" on the left and the signup panel on the right).
It was not a complicated build by any means but I liked the concept it developed and it was dead-easy to make it all happen. I think the ideas in the UI are very good. Still rough, but you can see where this could go, and it's got a ton of potential.
I mean, it's fine and serves it's purpose, but I'm a bit confused what you are getting that you wouldn't get with the millions of pre-made designs and design systems? Like Tailwind UI for example.
I find that with the ubiquity of Tailwind, developers treat design as a "solved problem". What's missing is the specific evolution of one's product and the resultant information architecture. The sibling response is my experience as well, design is an incredibly interactive exercise.
Granted, not every component on every surface will need this amount of scrutiny. But I'm usually the outlier developer warning teammates that design is not a solved problem. Granted, there's a huge difference between an existing app and its evolution and throwing a nextjs landing page up in search of any life.
Even with bootstrap, design was a solved problem. What you bring with a UI designer is appeal (aka make thing pretty and enjoyable). If you want utilitarian, even the old x11 toolkit like Athena, Win 98 era widgets would do the part.
I wouldn’t, but you’re not much of a product designer if you can’t get your ideas across using simple tools like a sketch on a whiteboard (there was|is an app the let you take photos and link them using active areas).
So you can take bootstrap (or even raw html) and create something useful. Then you make it nice, not the other way around.
You would have to be a big outlier to feel the need to create a custom widget. Most widgets have been defined since decades.
I agree that design is about primitives. wireframes and IA should come across clearly at any fidelity.
But i don't think that's what tailwind and bootstrap are doing. But people very much use these tools to "solve design".
The layouts, widgets, and primitives in these tools are not primitives. I can't deny they get tons of people very far very fast. But my main disagreement is that all of this isn't design and it's not what designers do. You touched on what i agree with: UX flows, diagrams, stories, journeys, personas, etc, these all need to be designed and connected in reality using various primitives for the medium.
Then you slap a cohesive paint job on it, interaction elements, tone and terminology and yes, there is that element of design too.
Iterative experience (experimenting with different ideas, deciding what works best) and speed of execution (once I was happy with it, making it happen required almost no work).
Yes. Even without Claude design and just Claude code, it can use existing design and build out new mockups in-app, which is much easier to demo , tweak and then implement the backend (if any) - all through Claude Code (or Codex if you prefer that). We use both and are now leaning more towards Codex over Claude
• Claude Design uses Opus 4.7, which is more expensive than earlier models.
• It's just Day 2; it's not a finished product. It's ridiculous how quickly Anthropic iterates.
• If you've been using Claude for a while, Design already knows your style and preferences. You'd have to start from scratch using a different AI design tool. I don’t doubt that'll pay dividends in the long run.
> It will never be cheaper than what it is today. Anthropic is heavily subsidizing.
We don't know that for sure—they've dropped prices before:
1. Claude 3 → Claude 3.5/3.7 generation (mid-2024 to early 2025): Haiku went from $0.25/$1.25 to $0.80/$4.00 per MTok — this was actually a price increase for Haiku, but Sonnet stayed flat at $3/$15 while delivering significantly better performance, effectively a price-per-capability reduction.
2. Claude 3/4 Opus → Claude Opus 4.5/4.6 (late 2025): This was the big one. Opus dropped from $15/$75 per MTok down to $5/$25 per MTok — a 67% reduction on input and output. This is the most significant explicit price cut Anthropic has made, delivering a far more capable model at one-third the price.
They're definitely not subsidizing API pricing, can't believe how prevalent that fallacy is on HN of all places. The question is how profitable Claude Code is. Your example 2 is real and major but your example 1 is ridiculous, almost any new model from any company is better at the same price, and how is increasing the price an example of decreasing prices??
BTW, Github Copilot is pricing Opus 4.7 at 2.5x the cost of Opus 4.6 at promotional pricing (so maybe it'll be 4-5x). But Github's request based pricing is insane, completely divorced from their actual costs (you can achieve 1+M tokens for $0.10 if you give it a large request), so I'd assume they're losing a lot of money.
The cost of a thing, is relative to its source costs. They are subsidizing API pricing, if you consider all the costs to provide the service, including all model creation, training, etc costs.
But that doesn't mean they will be more expensive, longer term. The cost of compute will go down as time goes on. Each year it will get cheaper. Same for power requirements, computing density, cooling, and so on.
I remember trying to store and play mp3 files on older computers. I could typically hold a few on a disk, and if I wasn't doing anything else I could play one. Barely. Now you'll be hard pressed to play an mp3 and see the load results in top or what not.
If those cost of compute is going down, then eventually it will go down enough that we will run on our LLMs locally and Anthropic will go out of business.
> then eventually it will go down enough that we will run on our LLMs locally and Anthropic will go out of business.
I want robust local LLMs as much as the next person—Gemma E2B, 3.2GB does my word completions as I type. It's gotten to the point where it knows what I'm going to type before I do!
But I don't see Anthropic going out of business anytime soon. As good as some of the open source LLMs are, we’re still a long way from being able to frontier models at home.
If you are using LLMs for tool use locally, then in a decade it will not make sense anymore to pay for hosted solutions. Your device will have compute power to run powerful LLMs trivially.
If you need LLMs at scale to serve many customers, then hosted solutions make sense for the availability aspect. But by this point models can be offered by any generic services provider, like AWS or Cloudflare. Pure AI companies that just offer hosted models and nothing else will go extinct if they don’t expand to offer more services.
> If you are using LLMs for tool use locally, then in a decade it will not make sense anymore to pay for hosted solutions. Your device will have compute power to run powerful LLMs trivially.
LLMs a couple of years ago that'd be impossible to run on consumer hardware are now running on consumer hardware. I'm less concerned about compute power; it's more about memory.
It could be several years before new RAM capacity comes online. Even then, it won't be cheap.
I expect in the future, hosted frontier models will be a utility like electricity or cable tv. Part of a package most people will subscribe to.
> can't believe how prevalent that fallacy is on HN of all places
AI is very emotional for a lot of people leading to bias takes in both directions. We like to think HN is more rational than average, but we’re all human.
It's in research preview. I suspect limits are low on purpose. FWIW, I gave it twelve screenshots of different pages in my app and it did a really excellent job fixing them up. Consumed just 40% of weekly quota - still too high but it's probably a YMMV situation.
It produced great results for me, in 10 mins, and then my usage was blown and now I have to wait a week. It did let me export the ZIP, though. I tried throwing the contents of the ZIP into Stitch With Google, but it didn't work very well.
Yup it's based off their playground so plaything is the right word.
It's a wrapper around that. I definitely appreciate the better design output from Claude code but it has a ways to go before it can replace serious design contenders.
I don’t really buy that Claude Design will remove all the complexity around design. Vibe-coded apps using Claude look simpler because they are simpler. They’re not a gigantic product suite with extremely specific UI components tailored to each use case. The ‘simplicity’ is an illusion coming from conflating the complexity of a bicycle (a vibe coded app) with an airplane (an app like Figma).
Building the same design system component in code versus in Figma is going to be slightly more succinct in code; Figma’s primitives don’t have the sort of conditionals and control flow that code has. But code is much less malleable than drawing on a screen, and creative freedom is harder to achieve in code.
UI can fix the gap where code feels less malleable than Figma, but complexity comes largely from the worlds that humans create, and humans apparently want to create 8 modes for 4 products and 2 light/dark modes. If you want the same setup in Claude, it’ll be a little easier to maintain, but not much less complex.
I admit I'm having a visceral reaction to this analogy. A bicycle is a sophisticated product whose form is almost pure function. Despite being apparenty simple, almost no regular person can draw even a reasonable facsimile of a bicycle from memory ( https://www.youtube.com/watch?v=L0_vXZ-3LFU ). Which is to say, for actually designing a functioning bicycle, the devil is in the details, and details are exactly where vibecoded apps fall down. Our lower bound for this analogy should instead be the downhill go-kart cobbled together from scrap wood you found in the dumpster.
Figma has been in trouble for a while. All the designers at my company switched to Cursor nearly a year ago. They made live mockups that don’t even need a spec to implement, because the expected behavior is already captured in the prototype. Claude Design makes it just marginally easier.
Not to mention all the people hiring UX just because they don't want to deal with it themselves, not because they need something that requires a lot of skill.
Stitch has been around for a few months from hole and it does a better job than this. I bet designers are in the honeymoon phase of people don’t know this exists and this does my whole job phase.
Feels like a lot of them are using Bootstrap, curated Tailwind elements or Wordpress templates. In which case the challenge Anthropic faces is convincing them the extra flexibility and magical "type into prompt" approach to customization of Claude Design is worth the compute cost...
Figma is answering a different question which is "are you prepared to spend time and money on full time designers to have pixel perfect layouts agreed with managers and consistent across platforms" and non-AI tooling has been orders of magnitude faster and cheaper at generating something that looks good enough as end results rather than mockups since before it existed.
So let me get this straight (Pretend I'm 50, a developer since childhood, but I can't CSS to save my life) are there shops where developers, even front end developers, have to talk to designers who are't just sketching an idea for a logo or landing page, but designers who run this Figma thing and maintain the entire products "design" in some "style database"? And the idea is that these designers - who aren't developers - should be able to tweak the look of things without changing code? Or is it usually just the front end devs that run this Figma thing, but they dislike the disconnect between it and their code?
lol yes. At least in agency world, a common approach in the last X years has been that designers create entire pixel-perfect, component-based sources-of-truth in Figma (which evolve! they aren't delivered static and complete) -- these are also what the client sees and approves, or at the very least they see branded deck slides that incorporate the Figma designs. Anyways, front end then re-implements from Figma into CSS, except it's usually best-approximation (not pixel-perfect) partially because, despite Figma allowing you to "copy CSS" for an element, it's unusable, almost inline CSS (and usually not aware of its ascendents and descendents, or any variables you're maintaining in CSS, or any class hierarchies, etc), and partially because the units of measurement aren't always identical on either side. You'll also often have multiple FE devs recreating components independently of each other (as a team effort), which can lead to drift and different implementations, which is fun. Then, depending upon the tech stack, FE might be building these components in something like Storybook [0] as a "front end source of truth", which then are either directly injected into a React or NextJS app or whatever, or sometimes they're partially or fully re-implemented again into BE components in the CMS (ex. Sitefinity). Then people ask which one is the source of truth, but really it's a chain of sources of truth that looks more like the telephone game than a canonical "brand bible". Then throw in any out-of-the-box future client efforts (say, a promotional landing page hosted outside of the main project) and you may have yet another reimplementation of part of the same design, but in a completely different system.
It used to be worse, these days you can at least link between storybook and figma and have similar component naming and figma mostly uses css mental model. Before we had invision and sketch and designers and developers lived in their own worlds that were just completely disjoined.
Don’t hire anyone that is a front end designer and doesn’t implement their own CSS. This applied 15 years ago when it was photoshop people faking design skills.
Architects draft buildings on computer because building in the real world is time consuming, expensive, and cannot be undone.
It's says something about the way things are now that we no longer go straight to building the digital interface, but instead make a fake digital interface first.
Yah you get this inner platform effect where designers start unwittingly creating their own version of css using Figma and it gets really bespoke really fast.
@kevinsync's answer is 100% correct and it's been this way for the last ~~~20? years? at least - only it was "Photoshop files hold the (design) truth" before - now it's figma.
But yes, the "design to code" gap has always been where designers' intentions were butchered and/or where frontend developers would discover/have to deal with designs that didn't take into account that some strings need more space, or what to do when there are more or less elements in a component, how things should scroll in real life, how things should react to a variety of screen sizes, etc.
this short meme video is funny/not funny because it hits too close to home - https://www.youtube.com/shorts/r6JXc4zfWw4 - but yes, "designers don't code and developers don't design", roughly speaking
and then of course you meet some people who do both really well... but they are pretty rare. :-)
It's a real shame that people bought into this false dichotomy, because the base reality is that people who work in web dev that stubbornly pick either code or layout are more of a liability than an asset.
I don't believe that people who can design and code are as rare as folks seem to believe, either. What seems more likely is that there are a LOT of coders who are extremely fluent in CSS but aren't particularly gifted when it comes to making things look good.
It wasn't that long ago that designers understood that they couldn't just hand off a 2D comp of what they want to see. The job isn't done until the output can be integrated into the app. Nobody gets to launch cows over the wall and go for lunch.
Nah yeah Photoshop .PSD's were totally normal for website designs. I got extremely proficient at building functioning websites based on PSD files, going back as far as the days of using nested <table> structures with 1x1 transparent spacer.gif images :) I built hundreds of websites from .PSD files, and Fireworks was pretty much non-existent in my experience.
Yeah +1, at the start of my career (mid 2000s) all the web designs were done in Photoshop. I think this was true until 2010/11 at least, when I first encountered Axure being used for some design stuff. I’ve never used Fireworks and never saw it in the wild (UK, in case it was a regional thing)
Sure, and also Illustrator sometimes, and Photoshop at other times. Some of the designers I know (very famous for their ui/web work) never touched vector components and just had a ton of layers in Photoshop and air/paintbrushed everything. Hence the meme...
I wouldn't even classify it as a mistake, just a difference in experience regardless of what Adobe's intentions were.
As someone who has done front-end development for both web and mobile devices for a very long time in the pre-Figma days I was handed a lot more designs that were mocked up in Photoshop than Fireworks.
UX designers I encountered have mostly been tasked on ensuring consistency across the various product (A lot of devs are very cavalier about spacing and font sizes). Sometimes they proposed new flows and layouts, especially when the product needs a coat of paint.
So tools like Figma is nice in that regards as it's simpler to iterate on (From simple to hardest: Sketch on whiteboard|paper, Wireframe tools like Balsimiq, Figma|Sketch, css code) because it's pure fiddling with various properties. Figma has direct feedback while the code may require a compilation phase.
Yes, Figma is the de facto standard for how designers hand off a UI design to developers in large (and some small) companies.
It's kind of horrible, but I guess it's better than previous alternatives. But, it's not better than a tool that works with code directly and mostly automates away the tedium or translating a visual design into code. I haven't tried Claude Design, but I know I don't find Figma enjoyable (but I'm not much of a designer...I'm more comfortable with code than with pages and pages of options in a GUI).
I'm not sure about "without changing code" but I have definitely seen the believe that Figma represents something authoritative about the product instead of, say, the product being authoritative for itself.
Perhaps because I have a similar bio to yours, I am allergic to this view.
As someone who spent quite some times these days to reverse the figma protocol[0] I can't agree more with
> Figma accidentally excluded themselves from the training data that would have made them relevant in the agentic era.
Their binary format is so much of a "let's reinvent everything" which I think come from the fact it's a tool you can use for web design, android app design, ios design and anything-you-want design that it became a jack of all trade and so mapping it to web is not a perfect 1:1 translation.
And for being useful to agent, any people who got to implement the figma from a UX guy know that even human can't know truly the intent of most figma design, so how a LLM could ? Common source of question that even the UX guy has no answer for:
1. Ok this button looks great, but in German how will it look ?
2. Oh and actually this button does not look great when i put in CSS, it wraps on two line, you cheated again with the letter spacing, did you ?
3. How does it look on a phone that is not an iphone ?
4. You know that doing a border with a gradien is not possible in CSS, so what should i put ?
5. How does it look on a 4k screen ?
6. etc.
I know that most of these question can be answered by props and autolayout, and I've been asking the 5 question above these days on a figma that had these but it's just that the UX guy is not that mythical beast that "know-how-to-use-figma-right"
So I can't wait for these tools that are html behind to catch up, even more if we can have the prompt with it. (As a developer I never got to see the prompt the product manager made to the UX guy)
Great article, the last couple of paragraphs made me laugh! I love the part about things not masquerading as something else and being honest about what they are.
I was wondering if PenPot (https://penpot.app) might be sitting pretty in this new agentic era, considering that they took the direction of designs being actual markup, unlike the canvas approach in fig - if that’s even something that interests them.
I've worked on design tools for the last few years.
This article is a fundamental misunderstanding of both the design space, and figma as a company.
Just a few of my thoughts:
- Figma was always about building a successful company over a successful product. Figma started with a much more ambitious aspiration, and had the ability to deliver through talent like Evan Wallace. A lot of it started with showing how capable webgl was in the browser. And yet, a lot of things like 3d features don't exist because they had the awareness to really hone in and focus on building a specific thing that made them money because everybody in the company ended up with an expensive seat price.
- Seriously, Figma is a company that's about design tool second, and about getting a product that businesses use first. To that end, it's already succeeded through the IPO, subsequently, who knows what the market is going to look like. Figma having a war chest is in many ways much better than having a technically impressive demo that might evaporate.
- People at Figma, 100%, know everything in this article. And not just figma people, like anybody and everybody that's tried to build a design tool has had these thoughts. It's very obvious that ui/ux is the interesection of design/dev/pm. It's also very obvious that it should stick close to the source of truth, to something like code.
- The problem is, that it's almost underselling it to say that it's MASSIVE challenge to execute on these ideas because of how easily it bleeds into building not just a design tool, but a coding, data management, architecture, etc. tool
- I could talk at length about all the challenges and potential solutions, but that's neither here nor there.
- On AI, I guess other people's guess is as good as mine, but my gut feeling is that while data is important, SOTA AI is generalist enough that the base models, the thinking they're able to do, is better than having a lot of custom data. Especially because ui design is front-facing - you can just scour the web in contrast to private financial documents, or legal documents for example.
This design tool space died a long time ago for me when InVision shut down and pivoted to a digital whiteboard. It’s a really difficult space.
But the fundamental problem is that it’s hard to get a design system right long-term, especially because it’s so intertwined with your code and whatever component library you use, which is a layer your designer will never touch. I don’t really see Claude Design fixing the fundamental Storybook hell of designing reusable and pretty components and layouts, but I don’t see Figma or any other tool solving it either.
What’s the solution? It feels like something that needs to be fixed more deeply at the component level.
The solution is an open, flexible, scriptable and drawable canvas where design and code co-exist in exact harmony. Design changes directly modify front-end code, and front-end code directly modifies design equivalently. I see the endgame as a model where designers and FEE's are co-owners and co-authors of the front-end with zero handoff.
What if the approach isn't reusable, but instead is rebuildable? We are stuck in the mindset of creating components that we can grab and plug in to new designs. When we have a component that we like, why not ask the tool to create a markdown definition of it. Later on, when we're doing a new design where we would like to reuse that component, we tell the tool to read the markdown and use that whenever they need to use that component. I think the future will be much more flexible and interesting.
I don’t know what level of complexity you’ve seen in your software buildouts, but at anything “enterprise” scale, building your own components from scratch is a recipe for absolute disaster. There are so many nuances, especially with accessibility, and edge case bugs, that I would really strongly recommend against it. And by extension, I’d be against this approach.
Maybe you could make it work if everyone agrees on a base set of headless components to use, but we seem to be moving in the opposite direction with things like ShadCN.
> I don’t really see Claude Design fixing the fundamental Storybook hell of designing reusable and pretty components and layouts
FWIW Claude Code is decent at scaffolding those out if you have a good set of examples for it to work from.
But the argument is that is unneeded as we move forward as making changes and extracting things and such becomes basically "free". I'm not so convinced, but I do see the argument.
Some good points, but as a whole - I'm not sure if I agree. Sketch lost to Figma because of it's design tooling & multiplayer. Physical products still get designed before being constructed - I don't see that going away. If anything, I think Figma should stop trying to play both sides of the field and decide what it wants to be.
> Sketch lost to Figma because of it's design tooling & multiplayer.
Or maybe because you could just send a Figma link to anyone in your org and it opened in the browser vs having to tell them to download some Mac app and open a specific file that will get outdated over time.
I tried yesterday for about an hour to have Claude design make me a simple logo (just the symbol) and didn’t get anywhere good. I’m sure for certain things like UI it’s great, and so is just Claude code, but this Claude Design thing very much to me feels like a demo and not a product. Maybe one day!
Claude Design is just a big opinionated prompt: https://www.lobsterpack.com/blog/claude-design-trenchcoat/. Among other things, it knows it isn't that great at drawing SVGs, so it won't try unless you force it to. For a logo, try drawing it with vanilla Claude Code as if it was a separate project: ask a "design agency" to ask you questions, answer them, then make a detailed brief of what you want to draw, then make it output an exact plan of what and where will it draw, lastly ask the chatbot to do the actual drawing using sub-agents for drawing individual components. Also add a "render it to a raster and make sure it looks right" step as well.
Sure, the blog post is AI generated (I'm not a native English speaker, our bunch is often shy about our English language skills), yet the research I've done there is manual.
I found it interesting that (contrary to the popular opinion) there wasn't some magic, e.g. a novel model, happening with Claude Design, especially magic enough that Figma wouldn't be able to replicate if they felt like it.
Also, apparently human (not artificial) neurons were behind that huge prompt, very well aware of the limitations of the model, cheating here and there to make Design's outputs more impressive, making it "create a (design) plan" beforehand, i.e. all the stuff that we the common laymen could do ourselves with the same tools.
> Also, you certainly got some brass, linking an entirely AI generated article in a forum where extreme distaste is registered for entirely AI generated posts.
> How is your comment not downvoted to oblivion?
I'm sure there's a polite way to say things.
I heavily dislike LLM content, but if you read the content, it's actually got information of value.
That was the polite way of saying things. The phrase "if you couldn't be bothered to write it why would anyone bother to read it" was a saying from usenet times.
The truth is it took the author less time to "write" that piece than you to read it. It's a blog. There's no deadline, and yet they couldn't take the time to actually type out their own thoughts.
> I heavily dislike LLM content, but if you read the content, it's actually got information of value.
If it was so valuable the author would have written it themselves.
The article makes a good point about how Figma's non-open data model is limiting their utility as the source of truth.
But I think it's part of a larger mistake Figma is making: they seem to have shifted to an extraction mindset too early, assuming they'd captured the market, right when the ground beneath them is starting to shift.
It's most visible in their pricing model evolution, which is now explicitly anti-collaboration. Figma used to be the obvious default because you could quickly share files with non-designers, so they could view and make small edits without fuss. Now that requires a paid "seat", along with a confusing mess of permission flows.
It's platform wide too. I taught a college design class recently, and had students sign up for Figma because it seemed archaic not to teach them to use it. Instead of just giving any ".edu" address a free account (like they used to) students are forced through a 3rd-party process of uploading transcripts to prove education status. A few of my students got rejected or ran into confusing errors, and never got access… Now I have to re-evaluate whether its worth using when teaching the class again. (And this is for a population with near-zero short-term purchasing power, but huge potential long-term value… why add barriers?)
This is such a weird self-inflicted wound for a collaboration platform to make. The big tools that won on collaboration (eg. Google Docs, GitHub) have understood that low-friction sharing is critical to becoming the default choice. And that being the default is a flywheel that drives adoption, both in users and in tooling.
It makes more sense if you see it through the lens of Figma trying to juice short-term numbers for their IPO. But it's sad to see because it had so much long-term potential.
Under that logic is a free trial a bait and switch? How about a 1-month free deal? How about what Adobe (and many others) do where they license to the school and students get it free until they graduate?
It seems like a really weird point to make, when you could just as easily argue that Figma giving their services for free to students is a gift that levels the playing field, by allowing students without means to gain experience with industry standard tools they might not have been exposed to otherwise.
> Under that logic is a free trial a bait and switch? How about a 1-month free deal? How about what Adobe (and many others) do where they license to the school and students get it free until they graduate?
No. The key difference being transparency. You know when signing up for a free trial what the actual long term costs will be and can plan for it.
We might be talking about different things. I was mostly replying to this line from the OP:
> But I think it's part of a larger mistake Figma is making: they seem to have shifted to an extraction mindset too early
I’m not sure if this was just awkward wording that seems to condone these type of strategies.
All these loss leading, vendor lockin strategies have distorted markets heavily. Complex tools cost a lot of money to develop; and if another player is just going to burn piles of cash from elsewhere to undercut you, it becomes a game of capital allocation and not individual product quality/costs. It’s terrible for consumers and a big reason why even common chat apps are barely functional.
That's fair. I'm also heavily opposed to VC-funded, market-distorting behaviors and the later extraction-oriented outcomes they produce. In this case I was framing it in terms that might be more widely received by folks who aren't, and pointing out that, even if that was their mindset and goal, they were still making a mistake strategically.
But I appreciate the reminder to not cede ground in wording, thanks.
Watching the hive mind of the industry go almost overnight from inVision to Figma shows there's just no mote in this segment... people can leave just as quickly as they came, have no loyalty, and are all about fashion and vibes.
I did graphic and motion design for 20+ years and been doing full stack dev for the last 6. It's very difficult to do both and excel at - especially in the frontend space where things move incredibly fast. As you try to excel at one, you'll feel left behind in the other. Very stressful.
Fashion designers can, in general, work with fabric, yes. And an interior designer should probably have some idea of how to paint at the very least. To me with web design so much of what matters is encoded in the CSS and HTML that it is the final design product. Anything produced before is a sketch, a concept, but it's not a design.
For example designers and developers both use the computer as their primary medium of working. Their outputs resemble each other very closely, despite having a different underlying form.
Contrast that to the interior designer building a house, well those are different mediums. There is no efficiency gain from the interior designer designing the plan and also implementing it. Where as with a designer working in code there is one.
Fashion designers do indeed make clothing by hand, it's a very important part of their craft. This example disproves your stance.
React, Nextjs, Vue, Nuxt, and Angular are pretty much what AI is the very best at coding in my experience. Probably because they are all meant to build essentially the same thing with different curtains.
Ever seen a vibe-coded react app? It's astounding how well SOTA LLMs can produce good looking code in detail, but zoom out to the architectural or broader picture and it becomes an unholy mess.
It's like a masterpiece painted by an artist with their nose 5 inches from the canvas at all times.
I've been a developer for over 2 decades and I've been using AI in our react codebase for the past 3 months. Outside of some optimizations there's not much a designer couldn't debug through Claude Code. 90% of the industry is toast.
I want to be wrong because I'm watching the death of my entire career, but everything I've seen is pointing to this as an inevitability. We are shipping better and more secure code, and doing it easily twice as fast. Many development teams can be cut in half today with no reduction in output. I don't want to say it out loud at work yet, but we're actually producing too much.
I've been writing code for 50 years and it looks now that we have seen sunrise and are about to see sunset on humans writing code by hand.
Is that bad? Not to anyone who has managed dev teams and is familiar with the incredibly tortuous and painful business of trying to corral a bunch of humans with varying skill and enthusiasm levels to create software. We have tied ourselves in knots with things like Agile just trying to work around the fact that software development is so slow and arduous.
Many times back in the waterfall days I have written up design documents to kick off dev teams on multi-week or month projects. Now I could feed those into Claude Code and get results in days. This stuff is exciting beyond belief in just getting shit done.
This is a golden era for any established company with an existing customer base. My question to them would be "with Claude Code, why aren't you carving through that massive backlog of feature requests that has been building up over the years?".
A lot of people seem to look at this as job threatening, and it surely is for junior devs. But for companies that already have a strong senior talent bench, it's time to raise the ambition levels and ask not how many jobs can be shed, but instead just how fast and hard can we go now we have these new superpowers.
This is so context-dependent. Coding some generic crud app is indeed becoming more automated, but most of the stuff I end up building is just way outside the capabilities of current LLMs to accomplish without significant steering and gasps hand written code. Most of the stuff LLMs are good at ones hotting are the same things a non-coder could build with no-code platforms anyways. Which is great imo, it means we can utilise our skills and expertise on stuff that is more "cutting edge".
We're moving so fast that management can't keep up on reading what's happening, they're going to slow development down by cutting the massive cost of employing people. There just aren't enough features to justify the breakneck pace.
It's a golden era for business, but the industry will employ many fewer people.
AI is impressive but this same sea-change happened at least twice before - the era when computers went from being rooms full of women(354) to machines programmed in machine language(892) to those with screens, keyboards and even assemblers (assembly language, especially macro assemblers, were considered seriously high level at a time), to mid-level languages like C (considered needlessly complex and slow at one time, now considered barely above a macro assembler), to high-level languages like Java and even higher ones (arguably) like Rust.
Every one of those transitions has resulted in more programmers - though not necessarily the same programmers.
But things really are different this time. Computers and software were nascent industries with lots of room to grow, lots of software to build in previous transitions. Today software and technology companies are the biggest in the world. Every industry uses software. Getting your web app, mobile app or game discovered is actually a huge problem today because we have so much software. There is not infinite demand for software, or for anything else, even if it seems that way in the early days.
The Olde Days were custom code for a business doing business things (only they could afford a computer, and some universities), then there was a Cambrian explosion of software sold by individuals or small developers to many (80s and 90s), then we've moved to large companies and SaaS.
I think we're about to cycle back to "custom code" except now it's for everyone, by AI - you don't need to find the to-do app of your dreams; you can code one for yourself in a fever-dream.
The era of "write Wolfenstein 3D in a few months and make millions" are gone, but they've been gone a long time already.
Or - there was a HN discussion on this half year or so ago - there's consolidation again, and there will be AI, but no code. Domain expert talks to the AI, perhaps with an expertised intermediary. AI spins up a whole new 'software platform' for the customer.. internally. Offers all the UI that is needed to work with it.. still 'in the cloud' i.e. in AI data centers. Customer happy, devs less happy.
AI isn't a technology that replaces programmers, it's a technology that replaces generic human beings. The manager of your agents will be an agent, too.
> Outside of some optimizations there's not much a designer couldn't debug through Claude Code. 90% of the industry is toast.
I've seen the "debugging" and "coding" that non-coding designers are attempting to vibe-code. 90% industry is definitely toast, but not the 90% you're thinking of. Most industry is going the way of Microsoft that cannot even display a start menu in under a second
Realistically this doesn't mean all pure designers go away. Large orgs can have a small team that set the overall style guide and designs important pages, and the rest of the org just follows using AI to iterate.
That's the kind of question you will have to ask if you don't hire right. I get collapsing frontend/backend and PM/UI/UX but two then collapse code and product may be a bridge too far.
All right, here's a statement: your designers won't even know when the code is wrong. Just because it compiles it doesn't mean it's fine. They lack code judgment in the same way your coders lack design judgment.
In response I suggest that the engineers using AI also lack code judgement (because they are not reading it either). I don't think questioning the AI use is the actual topic here, it is the shifting roles. Who says it's the designers that are taking the new meta-role? It's probably the FE's honestly.
The role shifting doesn't mean that it's the best path forward. I'm simply stating that it is happening.
Your designers are going to be looking at the layout; they're not going to notice if it's slow, uses too much memory, is not maintainable, doesn't follow repo patterns, etc.
Do you think it is reasonable to expect a person with an arts degree to know this?
"This works but the app is slow, can you optimize it." I'm not even kidding, most of the time this is all that's needed. Repo patterns don't really matter because humans barely end up looking at the code.
We've had a customer send us a prototype of what they wanted built with AI, and they don't have a college degree in anything. It followed our codebase patterns without any prompting, included tests, and all we had to do was wire up the backend.
> Do you think it is reasonable to expect a person with an arts degree
Of course it is.
The only people who think your fucking college degree determines your knowledge level and ability are teenagers and people who are so deeply untalented that it’s the only way they feel qualified.
As we know from THERAC-25, etc., comprehensively verifying that code works the way it's expected to is not actually very easy - it's perhaps one of the hardest parts of building any system more complex than a toaster.
Worth noting that you've slipped from "checking whether something works is easy" to "well, it's probably not as harmful as a very notable failure if it fucks up."
>A leading question is a query that suggests the desired answer or puts words into a witness's mouth, often guiding them toward a "yes" or "no" response.
>Front-end, UX, design, and product have become one role.
Ok so, are your "designers" (now part of one role) not debugging react code? If they are then you mislabeled the question as leading to avoid discussing in good faith. If not, then you lied about the "one role" and it turns out that they haven't BECOME "one role".
This motte-and-bailey strategy is unproductive and disrespectful to the people you are addressing.
I miss the days of having a native desktop design app with a perpetual license.
What Figma achieved technically in the 2010s was amazing. Coded the app in C++ and then used WASM to deliver it as a multiplayer web app.
But now it's trying to be too many things. Why did they ever feel the need to add slides and this other stuff.
Their MCP is poor (sure, they'll improve it).
The app struggles with larger files and performance is sloppy.
And don't get me started trying to design data grid heavy apps.
And they could easily follow Adobe's lead. Enshittify and lock you out of your account whenever they feel it's necessary (remember what happened with Venezuelan Adobe users a few years ago?)
Either Penpot gets their act together and will become the opensource design canvas for open-weight AI models or we will see another open source solution that will fill this space.
> I miss the days of having a native desktop design app with a perpetual license.
You can go that route with Affinity Designer [1], owned by Canva, who partnered with Anthropic on Claude Design [2]:
We’ve loved collaborating with Anthropic over the past couple of years and share a deep focus on making complex things simple. At Canva, our mission has always been to empower the world to design, and that means bringing Canva to wherever ideas begin. We’re excited to build on our collaboration with Claude, making it seamless for people to bring ideas and drafts from Claude Design into Canva, where they instantly become fully editable and collaborative designs ready to refine, share, and publish.
I have it, jumped on the affinity band wagon years ago after Adobe started their enshittification process.
After Canva bought Affinity, you now have to authenticate with your email from time to time when you launch the desktop app. Annoying and why do they do that?
I got deeper into Figma than I ever had to before yesterday.
It turns out there’s no way to use Math in variables built in to the product. The most common plugin is 99 dollars. To add what is obviously mustache JS. To browser based software. It’s not good.
Stitch has way more usage allowance, and it has been absolutely fantastic for some things, but it can get trapped in weird places where whatever you tell it to do it thinks it did it, but it didn't. It's like that Family Guy blinds meme:
I feel like we're leaning way too much into the "vibe" aspect of using LLMs at the moment. There is definitely a good use case for LLM's here, but is just prompting your way into a design really the best method here? I feel like something in between Figma and Claude Design would give designers the control they want, but still removing the friction of going between design files and the code impl.
I tried Claude Design yesterday and fed it the UI of an app I am working on and what I had created already. I asked it to mock up 6 new "layout skins" using different colors, different icon and button placements, different vibes and it churned out 6 good designs with hi-res images plus Claude Code instructions and the ZIP file to boot. Didn't hit the usage, took about an hour. Did a really good overall and I liked the process and thinking structure and question asking.
As far as I'm aware, "source of truth" refers to data/code that drives the actual app, so Figma could never be a source of truth (Figma is a reference of what the app data/code is supposed to do). Saying Figma is a source of truth is like saying JIRA is a source of truth, which doesn't make any sense.
Excellent post. I share the author's sentiment which is essentially "to hell with Figma, at least fix Sketch". Been feeling very lonely in may hatred towards Figma, which is for a whole bunch of reasons (among others, it's an incredibly shitty, memory and CPU hungry Electron app that looks and feels worse than any more or less well designed web site), but now after reading this I realize the number of reasons has doubled.
It may look like a crappy Electron app, but Figma has a quite interesting architecture. The browser editor is developed in C++ and cross-compiled to JavaScript with emscripten. The rendering engine looks like its handling HTML, but it's actually rendering their own document format for cross-browser consistency. They have their own CRDT implementation to handle multi-user edits.
I think my biggest question is who cares? What does having an interesting internal architecture have to do with the “its electron though” ideological attack.
It is made to perform much better than your typical electron app would. Saying electron-based == shitty is complete misunderstanding of the technology. Although i dislike Figma as much as the next guy, their app was in many ways very impressive. See Figma's cofounder old articles at https://madebyevan.com/figma/
(author of the post here) I cut a paragraph how Figma costs cuckoo bananas money for your entire team for the privilege of enduring this byzantine nightmare. And they paywall certain features, which you likely can't get authorization for, so you have to do more hacks on top of hacks on top of the “gold standard” practices I shared in the blog post. The price ramp is not gradual.
man, I dont even use Figma for personal & side projects because its so expensive. I still occasionally fire up sketch or freehand it.
Figma is a work tool only and I'm disappointed by its MCP tooling which feels late and behind where it should be, I just feel forced to use Figma Make which stays in their walled garden without practical utility and connections to my actual codebases
> Figma invented its own primitives to make that work: components, styles, variables, props, and so on
Fireworks, Sketch, XD, Axure, etc all had these (or most of them) in some form before Figma even existed. Even illustrator, photoshop, etc have had the applicable ones for decades.
I promise I am fine lol, I actually had a really productive chat with their panel last year and found it wasn’t the right role for me anyway for some logistical reasons.
When you can control the model layer like Anthropic, you get more leverage over the traits of the persona, enough so that the system feels closer to havin consistent expert design judgment built-in that complements the 'truth-to-materials'.
> "To Figma: I can see a world where this post does numbers in the Figma internal Slack. If that’s the case and you’re reading this from Figma: this wouldn’t have happened if you hired me last year when I was interviewing. Your loss, big dawg."
What a counterproductive way to end an otherwise good set of points. Gives the appearance of bitterness and a desire for vengeance.
no real dog in the fight, and I don't even know if the OP's analysis is correct, but "they had a proprietary file format and got left behind because of it" always gives me a nice bit of schadenfreude.
Honestly, I never understood the move to create an artificial dichotomy between design and code with a heavy layer of tooling.
I suppose that a layout engine made sense in the context of Flash, and you saw the future of the web as a set of keyframe animations. But the notion that there's a lot of value in creating a very heavy, high-friction abstraction between the UI/UX and the platform it ultimately runs on was always going to be a loser.
In the end, it turns out we're all just web developers, regardless of your weapon of choice.
I was making a new brand file in Figma and was about to define all the variables and aliases, paths, all that. Took one look at it and just made the 8 colors I needed and went on with the design.
Oh no. Figma has variables and instances and it's hard to debug bad colors.
And here I am with Claude Code... That so far generated a 2000-line CSS file for a 7000-line app consisting of literally three web pages [1]. Where almost every single color, component, class and style is duplicated at least two times. Where custom classes are fighting with Tailwind classes (yes, there's also Tailwind ON TOP of custom CSS) that are fighting with inline hardcoded style= declarations.
Figma is definitely going to suffer the vibe-coded design slop-app from Anthropic.
[1] 7k lines are almost justified for the functionality in them, and I tried to keep an eye on the code. It's harder to keep an eye on CSS
Have had similar dramas with CSS. Opus/Sonnet seem to have far less taste and discipline in writing CSS - constantly they are trying to slam in changes with !important or inline styles rather than think through how to do it properly.
We can blame AI for slopcoding but it's just what we've been doing for decades now - who cares if it takes 9000 lines to do what in theory Linus and Knuth and Carmack could do in 3000? Our CPUs eat a million lines of code for breakfast and demand more.
what are they talking about product teams needed to justify themselves? a good product guy's job is to talk to the users and figure out what to build. My job is to figure out HOW to make it happen. Neither side need to justify themselves. Good product people are vital to making sure engineers don't spend months building the wrong thing.
A lot of engineers find it difficult to conceive of product and design (and marketing, and management…) as actual skilled work. It’s all con artistry orbiting engineering.
I used it today to take a look at my previously built design system with Logos, branding, fonts, and everything else. After a lot of annoying tweaking back and forth, finally, I got something that was satisfactory.
Then I looked at the usage and it said I had used 95% of my Claude design usage for the week!
This isn't a real tool. This is a plaything, if that's what they're providing as examples.
I used Claude Design to see how it'd spit out a design I already had been working on for some weeks, given a dense enough prompt and a decent requirements document (I did not feed it visuals). I thought the output was pretty good! It didn't match the style we're after at all but it did do some logical content grouping and made some IA decisions I decided to pull into my own explorations. Overall I left with a good impression.
And then I was scrolling Twitter, and saw someone else post their own "success story" and the design was nearly identical to the mock up Claude Design made for me. Lol. The homogenization problem will continue to plague tools like these to some degree, much in the same way AI generated text or code or imagery has a sort of homogenous tone or feel to it.
Homogenous might be awesome. I miss predictable UIs.
Damn you just made me realize.
We used to have everything having personality but being consistent as far as UX goes.
Now everything looks like tax forms and the UX is all over the place.
That’s because designers stopped caring about following each platform’s guidelines because they want to spread “brand recognition” or some shit like that.
This is kind of a revisionist view of software. I think most of the consistency we remember from software past is because skipping the OS tollboxes and doing your own custom UI was hard rather than because most software developers cared about consistency. Yes the OS vendors did, but one doesn't need to go far to find applications that very much did their own thing. "Bubbly" and "goopy" UIs of the sort "Kai's Power Tools" exemplified were all over in the 90's. Everyone's favorite Winamp was famously not using the standard UI toolkits and had a heavily customizable UI. To say nothing of the many software packages that used the standard toolkits only far enough to give you a window that was then filled with some sort of Macromedia or similar UI that was then completely proprietary to the application itself (think encyclopedia and other educational software of the day). Even the OS vendors couldn't help themselves sometimes (looking at you QuickTime 7)
If older software was more consistent, it's only because the OS didn't provide nearly the same degree of customization options that HTML and CSS provide developers today. Not because of some pride in consistency.
At least in the goopy days it was VERY clear what was and was not a button.
This exudes everywhere. I've had cases of where some weirdo company changes their packaging on, say, soap... and now I literally can't find what I used to use. The logic is that some other company is cloning their look, so they want to "stand out" again, and thus change theirs.
Sometimes, I'll manage to find the brand with the new colours and logo. But often even then, I can't find the specific product from that brand. They've changed it so much I can't tell which version I picked before. Which makes me look for something more like what I used to have.
Good job "standing out" guys. I'd say literally maybe 1/3 of the time, I've just literally lost products. I don't know the name, just how it looks.
It’s not the designers pushing that, it’s the product managers and marketers. UXDs generally roll their eyes at pure branding stuff.
Guess it’s a bit of both.
Whenever I said “this is a website, not an app” I would get confused looks from designers.
UX people fight some of the BS, but “looking pretty” usually wins over “being useful”.
Homogenous doesn't work when you're Google and your product comes out looking like Microsoft.
Good design is distinctive. No one wants a world where everything looks the same.
If I’m buying art for my wall, I want variety.
If I’m slamming the brake pedal in a car, I want consistency.
Too much software in the latter thinks it’s part of the former.
A hammer should look like a hammer, a saw should look like a saw.
Good design follows the function. Not distinctiveness per se.
If it's an interface and not an art object, then the design is secondary to the function of said interface.
Good hammer is a good hammer, not a "distinctive" hammer.
Distinctive hammers and other tools get brand recognition and free marketing out in the field, ostensibly increasing sales - that's why all the tool companies have their distinct colors and you can see the type of tool someone uses from a distance. Matching chargers/batteries incompatible with other brands perpetuate this even further.
Someone IS designing all this, they just aren't optimizing for what you wish they were.
For any serious tool, the brand recognition is secondary. It might be a different color, but the function is the more important part.
Design is too broad a word for what is being discussed here and often in the world at large.
Still, to me, good design is intuitive. I look at the thing, and I know how to use it. If it looks great and distinctive, even better. But most outlandishly distinctive design I've (consciously?) found is terrible.
Obviously, these short sentences hide a lot:
- To know how to use things, I must have prior experience. But different users have different prior experiences and acquired design patterns (i.e. interaction patterns)
- My knowledge of the domain is also different from that of other users.
- The way I interact with the system is affected by many factors (e.g. accessibility related concerns, zoom, etc.)
- Intuition is not magic. It comes after training as well. Good design is discoverable. Extraordinary design reinforces its own patterns seamlessly, so that I learn it without even knowing I'm learning (see: hidden tutorials in game design). I also include here the incredible attributes of good design that far predate computer-related design (e.g. how an icon should be recognizable just by its silhouette, or how apps "invisibly" teach us what each color or even section of the screen means).
- My incentive to learn (sometimes "tolerate") the design depends on many variables. Some of these include the design's "taste", yes. Others depend on how much my boss/client is paying me to "use this shit".
I wouldn't say I want a world where everything looks the same, but I certainly want one where everything works the same, and some geniuses once in a while add something new to my list of known (and loved) design patterns. I am not anti-design-experiments, but I will take a predictable UI that looks like windows 98 everyday over some "distinctive" shit that breaks all manner of expected behaviors (from keyboard shortcuts, to colors, to button placement, to relative sizing, to........)
If "everything looks the same" means no more branding obsession, sign me up.
I would take every news site delivering straight text, and letting me pick the page layout template to apply to all of them. Some kind of markup language that could be transmitted and then respect the users preferences as far as rendering.
I think its good that HN and reddit are basically the same, or that all old forums were basically the same but with different color schemes. Homogeneity is a blessing for UX.
Honestly, HN and Reddit are almost as different as threaded discussion forums are possible to be, especially New Reddit with it's "click hundreds of times to unhide most of the text on this page" approach to threading. Reddit's overall design aesthetic is all about pictures and headings and sidebars, and even minor details like the up/down arrows look different and are placed in a different relative position. The only design element they've got in common is Verdana, and that simply because when the websites were launched you only had two widely-installed sans-serif fonts to choose from...
We can have both distinctive designs and predictable UX. In fact, we did, for several decades!
Agreed. I miss the quirky UXes of the past. Kai Power Tools was one great example.
Everything? No. Software? Absolutely.
It’s really difficult to make a design that is usable, follows platform standards, yet has unique personality.
I mean, really difficult.
Coming up with a design that relies exclusively on platform standards is easy, “low-hanging fruit.”
I write stuff for iOS/MacOS/WatchOS. There’s tremendous pressure to follow platform standards. In fact, if you use SwiftUI, it’s very hard to deviate from them. SwiftUI makes it easy (crazy easy) to follow the herd, and downright miserable, if you want to blaze your own trail.
90% of the time, that’s actually a good thing. I get pretty sick of designers that refuse to compromise, and believe that their graphic opus is more important than usable UI. It’s even worse, if the designer is an engineer, with little background in graphic design.
A designer that knows how to compromise, and work with usability, is a unicorn. If you have one, keep them.
Like the code that LLMs produce, I expect the designs to be fairly low-effort, but that will be a good thing, overall. They will be effective and usable. We need more of that.
> I used it today to take a look at my previously built design system with Logos, branding, fonts, and everything else.
The fact that you are using this language tells me you are probably more advanced than the average individual, and likely have higher expectations.
My sister-in-law has a small apparel company. She’s developed quite a bit of skill over the past six years but she really struggled at the start. She had great ideas, but translating them to something she could apply was frustrating. *Anything* that could have helped her there would have been worth a look.
> The fact that you are using this language tells me you are probably more advanced than the average individual, and likely have higher expectations.
I am terrible at frontend, but I’m a decent engineer, and I needed to do frontend with AI a few weeks ago. The first thing I did is figure out how other people manage this; apparently there’s a whole design system made of atoms, molecules and organisms that works well.
I asked Claude about this, set up a workflow together, and now I have a design system markdown, maintaining the design standards using the atoms etc vocabulary, and it works really well.
If I can pick this up in a few days, most people that are serious about design are able to as well.
I've never heard of this design system. Do you have any decent referencs?
https://atomicdesign.bradfrost.com/
Funny. My read on that language was this person has absolutely no idea what a truly robust and scalable design system and component library actually are, particularly within the scope of a successful business. Well built ones serve every facet of the organization, not just the product.
Apologies to parent. This reply was intended for a separate thread.
I had a similar experience with running out of usage quite quickly, after setting up one design system properly, and then getting pretty close with a second one. But it's a research preview - I'm sure it will change.
I was quite happy with what I pulled off using the first design system: I wanted a new footer section for my IPAAS startup, it generated four options, the fourth of which was quite good. We iterated on it for a bit, then I pulled it into Claude Code (that integrated feature is very cool), CC built it, I deployed it, done. (Bottom section of https://tediware.com/ if you're interested, the bit with "Origin story" on the left and the signup panel on the right).
It was not a complicated build by any means but I liked the concept it developed and it was dead-easy to make it all happen. I think the ideas in the UI are very good. Still rough, but you can see where this could go, and it's got a ton of potential.
I mean, it's fine and serves it's purpose, but I'm a bit confused what you are getting that you wouldn't get with the millions of pre-made designs and design systems? Like Tailwind UI for example.
https://tailwindcss.com/plus/ui-blocks
I find that with the ubiquity of Tailwind, developers treat design as a "solved problem". What's missing is the specific evolution of one's product and the resultant information architecture. The sibling response is my experience as well, design is an incredibly interactive exercise.
Granted, not every component on every surface will need this amount of scrutiny. But I'm usually the outlier developer warning teammates that design is not a solved problem. Granted, there's a huge difference between an existing app and its evolution and throwing a nextjs landing page up in search of any life.
Even with bootstrap, design was a solved problem. What you bring with a UI designer is appeal (aka make thing pretty and enjoyable). If you want utilitarian, even the old x11 toolkit like Athena, Win 98 era widgets would do the part.
This is just completely false. But I have a feeling there's no way you're going to change your mind.
"make things pretty" would be a graphic designer or artist. Are you saying the entire arm of Product design is a made up value?
I wouldn’t, but you’re not much of a product designer if you can’t get your ideas across using simple tools like a sketch on a whiteboard (there was|is an app the let you take photos and link them using active areas).
So you can take bootstrap (or even raw html) and create something useful. Then you make it nice, not the other way around.
You would have to be a big outlier to feel the need to create a custom widget. Most widgets have been defined since decades.
I agree that design is about primitives. wireframes and IA should come across clearly at any fidelity.
But i don't think that's what tailwind and bootstrap are doing. But people very much use these tools to "solve design".
The layouts, widgets, and primitives in these tools are not primitives. I can't deny they get tons of people very far very fast. But my main disagreement is that all of this isn't design and it's not what designers do. You touched on what i agree with: UX flows, diagrams, stories, journeys, personas, etc, these all need to be designed and connected in reality using various primitives for the medium.
Then you slap a cohesive paint job on it, interaction elements, tone and terminology and yes, there is that element of design too.
> So you can take bootstrap (or even raw html) and create something useful. Then you make it nice, not the other way around.
Design with a capital D is a completely different realm than whatever you’re talking about. Not even in the same ballpark.
Iterative experience (experimenting with different ideas, deciding what works best) and speed of execution (once I was happy with it, making it happen required almost no work).
Thats fair. Could you have the same iterative experience with an LLM, but starting with a prebuilt base and iterating from there?
Yes. Even without Claude design and just Claude code, it can use existing design and build out new mockups in-app, which is much easier to demo , tweak and then implement the backend (if any) - all through Claude Code (or Codex if you prefer that). We use both and are now leaning more towards Codex over Claude
Things to keep in mind:
• Claude Design uses Opus 4.7, which is more expensive than earlier models.
• It's just Day 2; it's not a finished product. It's ridiculous how quickly Anthropic iterates.
• If you've been using Claude for a while, Design already knows your style and preferences. You'd have to start from scratch using a different AI design tool. I don’t doubt that'll pay dividends in the long run.
It will never be cheaper than what it is today. Anthropic is heavily subsidizing.
Moore's law is alive and very well in AI.
> It will never be cheaper than what it is today. Anthropic is heavily subsidizing.
We don't know that for sure—they've dropped prices before:
1. Claude 3 → Claude 3.5/3.7 generation (mid-2024 to early 2025): Haiku went from $0.25/$1.25 to $0.80/$4.00 per MTok — this was actually a price increase for Haiku, but Sonnet stayed flat at $3/$15 while delivering significantly better performance, effectively a price-per-capability reduction.
2. Claude 3/4 Opus → Claude Opus 4.5/4.6 (late 2025): This was the big one. Opus dropped from $15/$75 per MTok down to $5/$25 per MTok — a 67% reduction on input and output. This is the most significant explicit price cut Anthropic has made, delivering a far more capable model at one-third the price.
They're definitely not subsidizing API pricing, can't believe how prevalent that fallacy is on HN of all places. The question is how profitable Claude Code is. Your example 2 is real and major but your example 1 is ridiculous, almost any new model from any company is better at the same price, and how is increasing the price an example of decreasing prices??
BTW, Github Copilot is pricing Opus 4.7 at 2.5x the cost of Opus 4.6 at promotional pricing (so maybe it'll be 4-5x). But Github's request based pricing is insane, completely divorced from their actual costs (you can achieve 1+M tokens for $0.10 if you give it a large request), so I'd assume they're losing a lot of money.
They're definitely not subsidizing API pricing
The cost of a thing, is relative to its source costs. They are subsidizing API pricing, if you consider all the costs to provide the service, including all model creation, training, etc costs.
But that doesn't mean they will be more expensive, longer term. The cost of compute will go down as time goes on. Each year it will get cheaper. Same for power requirements, computing density, cooling, and so on.
I remember trying to store and play mp3 files on older computers. I could typically hold a few on a disk, and if I wasn't doing anything else I could play one. Barely. Now you'll be hard pressed to play an mp3 and see the load results in top or what not.
The same will be true of AI in 20 years.
If those cost of compute is going down, then eventually it will go down enough that we will run on our LLMs locally and Anthropic will go out of business.
> then eventually it will go down enough that we will run on our LLMs locally and Anthropic will go out of business.
I want robust local LLMs as much as the next person—Gemma E2B, 3.2GB does my word completions as I type. It's gotten to the point where it knows what I'm going to type before I do!
But I don't see Anthropic going out of business anytime soon. As good as some of the open source LLMs are, we’re still a long way from being able to frontier models at home.
The industry will shift, yes. At some point, remote LLM compute will be like AWS.
Everyone can do baremetal at home and run on it, or VMs, containers. Many don't.
However, you'll still want the best model and toolset. So there is some place for them to pivot to. Something for them to sell or licence.
It will be interesting to see where the all lands, a decade from now. Who will be left?
If you are using LLMs for tool use locally, then in a decade it will not make sense anymore to pay for hosted solutions. Your device will have compute power to run powerful LLMs trivially.
If you need LLMs at scale to serve many customers, then hosted solutions make sense for the availability aspect. But by this point models can be offered by any generic services provider, like AWS or Cloudflare. Pure AI companies that just offer hosted models and nothing else will go extinct if they don’t expand to offer more services.
> If you are using LLMs for tool use locally, then in a decade it will not make sense anymore to pay for hosted solutions. Your device will have compute power to run powerful LLMs trivially.
LLMs a couple of years ago that'd be impossible to run on consumer hardware are now running on consumer hardware. I'm less concerned about compute power; it's more about memory.
It could be several years before new RAM capacity comes online. Even then, it won't be cheap.
I expect in the future, hosted frontier models will be a utility like electricity or cable tv. Part of a package most people will subscribe to.
> can't believe how prevalent that fallacy is on HN of all places
AI is very emotional for a lot of people leading to bias takes in both directions. We like to think HN is more rational than average, but we’re all human.
They can iterate fast, because their devs and only their devs have access to the best Claude Code on the planet.
They iterate fast because they slap different names at the same thing they’ve been selling for years now.
Be glad it's not Day 200: Opus models are only getting more expensive to use.
What plan are you on? That's a really critical piece of info to be able to evaluate your experience.
It's in research preview. I suspect limits are low on purpose. FWIW, I gave it twelve screenshots of different pages in my app and it did a really excellent job fixing them up. Consumed just 40% of weekly quota - still too high but it's probably a YMMV situation.
It produced great results for me, in 10 mins, and then my usage was blown and now I have to wait a week. It did let me export the ZIP, though. I tried throwing the contents of the ZIP into Stitch With Google, but it didn't work very well.
Yup it's based off their playground so plaything is the right word.
It's a wrapper around that. I definitely appreciate the better design output from Claude code but it has a ways to go before it can replace serious design contenders.
It's early.
Anthropic has managed to figure out a lot of reading in between the lines.
I'm not sure how this will be any different.
[dead]
[flagged]
I don’t really buy that Claude Design will remove all the complexity around design. Vibe-coded apps using Claude look simpler because they are simpler. They’re not a gigantic product suite with extremely specific UI components tailored to each use case. The ‘simplicity’ is an illusion coming from conflating the complexity of a bicycle (a vibe coded app) with an airplane (an app like Figma).
Building the same design system component in code versus in Figma is going to be slightly more succinct in code; Figma’s primitives don’t have the sort of conditionals and control flow that code has. But code is much less malleable than drawing on a screen, and creative freedom is harder to achieve in code.
UI can fix the gap where code feels less malleable than Figma, but complexity comes largely from the worlds that humans create, and humans apparently want to create 8 modes for 4 products and 2 light/dark modes. If you want the same setup in Claude, it’ll be a little easier to maintain, but not much less complex.
Most of the times people just want a bike or a car. Not everybody needs an airplane. This is going to hit Figma very hard.
I admit I'm having a visceral reaction to this analogy. A bicycle is a sophisticated product whose form is almost pure function. Despite being apparenty simple, almost no regular person can draw even a reasonable facsimile of a bicycle from memory ( https://www.youtube.com/watch?v=L0_vXZ-3LFU ). Which is to say, for actually designing a functioning bicycle, the devil is in the details, and details are exactly where vibecoded apps fall down. Our lower bound for this analogy should instead be the downhill go-kart cobbled together from scrap wood you found in the dumpster.
> Most of the times people just want a bike
with a pelican on it
that runs on a local model and looks better than Opus
Milestone achieved with Qwen3.6
Figma has been in trouble for a while. All the designers at my company switched to Cursor nearly a year ago. They made live mockups that don’t even need a spec to implement, because the expected behavior is already captured in the prototype. Claude Design makes it just marginally easier.
Not to mention all the people hiring UX just because they don't want to deal with it themselves, not because they need something that requires a lot of skill.
Stitch has been around for a few months from hole and it does a better job than this. I bet designers are in the honeymoon phase of people don’t know this exists and this does my whole job phase.
The people that want just a bicycle wasn't going to buy figma
Are those people using Figma?
Feels like a lot of them are using Bootstrap, curated Tailwind elements or Wordpress templates. In which case the challenge Anthropic faces is convincing them the extra flexibility and magical "type into prompt" approach to customization of Claude Design is worth the compute cost...
Figma is answering a different question which is "are you prepared to spend time and money on full time designers to have pixel perfect layouts agreed with managers and consistent across platforms" and non-AI tooling has been orders of magnitude faster and cheaper at generating something that looks good enough as end results rather than mockups since before it existed.
> Vibe-coded apps using Claude look simpler because they are simpler.
This one seems pretty decent?
* https://github.com/2GT-Media-Group-LLC/mikrotik-manager
It was recently Vibe coded by an IT savvy non-dev (or non-traditional-dev anyway ;> ):
* https://www.youtube.com/live/qhZ5q6tlwq0?si=tAtmb04_WwhyaGkn...
Note - If you want to try it out DO NOT deploy it on a hostile network. ie the public facing internet
Isn’t Figma actually the tool used to plan and design the “airplane” level app? (Which of course does not mean it can not be airplane level itself…)
Making the complexity simpler is the whole thing. Any software that does it wins.
So let me get this straight (Pretend I'm 50, a developer since childhood, but I can't CSS to save my life) are there shops where developers, even front end developers, have to talk to designers who are't just sketching an idea for a logo or landing page, but designers who run this Figma thing and maintain the entire products "design" in some "style database"? And the idea is that these designers - who aren't developers - should be able to tweak the look of things without changing code? Or is it usually just the front end devs that run this Figma thing, but they dislike the disconnect between it and their code?
lol yes. At least in agency world, a common approach in the last X years has been that designers create entire pixel-perfect, component-based sources-of-truth in Figma (which evolve! they aren't delivered static and complete) -- these are also what the client sees and approves, or at the very least they see branded deck slides that incorporate the Figma designs. Anyways, front end then re-implements from Figma into CSS, except it's usually best-approximation (not pixel-perfect) partially because, despite Figma allowing you to "copy CSS" for an element, it's unusable, almost inline CSS (and usually not aware of its ascendents and descendents, or any variables you're maintaining in CSS, or any class hierarchies, etc), and partially because the units of measurement aren't always identical on either side. You'll also often have multiple FE devs recreating components independently of each other (as a team effort), which can lead to drift and different implementations, which is fun. Then, depending upon the tech stack, FE might be building these components in something like Storybook [0] as a "front end source of truth", which then are either directly injected into a React or NextJS app or whatever, or sometimes they're partially or fully re-implemented again into BE components in the CMS (ex. Sitefinity). Then people ask which one is the source of truth, but really it's a chain of sources of truth that looks more like the telephone game than a canonical "brand bible". Then throw in any out-of-the-box future client efforts (say, a promotional landing page hosted outside of the main project) and you may have yet another reimplementation of part of the same design, but in a completely different system.
[0] https://storybook.js.org
I've directly experienced this and it is roughly as sane and effective as it sounds.
It used to be worse, these days you can at least link between storybook and figma and have similar component naming and figma mostly uses css mental model. Before we had invision and sketch and designers and developers lived in their own worlds that were just completely disjoined.
This is exactly my experience of working in an agency. Made worse by Figma defaulting to 1440px so every design only really works at that width.
We only have the Figma and Storybook layers (product not agency) but these two comments paint an accurate picture of the absurdity. Thank you!
Don’t hire anyone that is a front end designer and doesn’t implement their own CSS. This applied 15 years ago when it was photoshop people faking design skills.
Architects draft buildings on computer because building in the real world is time consuming, expensive, and cannot be undone.
It's says something about the way things are now that we no longer go straight to building the digital interface, but instead make a fake digital interface first.
Yah you get this inner platform effect where designers start unwittingly creating their own version of css using Figma and it gets really bespoke really fast.
Why don’t we just teach the designers code / the coders design? This feels very Programmer-Analyst split
https://youtu.be/-ahtp0sjA5U?si=iXwfIBcpJQvVX-AB
Just teach backend engineers to do frontend pixel perfect CSS!
Different fields.
Design management will say that they don’t want to limit the designers’ creativity.
@kevinsync's answer is 100% correct and it's been this way for the last ~~~20? years? at least - only it was "Photoshop files hold the (design) truth" before - now it's figma.
But yes, the "design to code" gap has always been where designers' intentions were butchered and/or where frontend developers would discover/have to deal with designs that didn't take into account that some strings need more space, or what to do when there are more or less elements in a component, how things should scroll in real life, how things should react to a variety of screen sizes, etc.
this short meme video is funny/not funny because it hits too close to home - https://www.youtube.com/shorts/r6JXc4zfWw4 - but yes, "designers don't code and developers don't design", roughly speaking
and then of course you meet some people who do both really well... but they are pretty rare. :-)
It's a real shame that people bought into this false dichotomy, because the base reality is that people who work in web dev that stubbornly pick either code or layout are more of a liability than an asset.
I don't believe that people who can design and code are as rare as folks seem to believe, either. What seems more likely is that there are a LOT of coders who are extremely fluent in CSS but aren't particularly gifted when it comes to making things look good.
It wasn't that long ago that designers understood that they couldn't just hand off a 2D comp of what they want to see. The job isn't done until the output can be integrated into the app. Nobody gets to launch cows over the wall and go for lunch.
> only it was "Photoshop files hold the (design) truth" before
You mean Fireworks. Photoshop was for graphic design. Web designers used Adobe Fireworks. Figma is a successor to Fireworks, not Photoshop.
Nah yeah Photoshop .PSD's were totally normal for website designs. I got extremely proficient at building functioning websites based on PSD files, going back as far as the days of using nested <table> structures with 1x1 transparent spacer.gif images :) I built hundreds of websites from .PSD files, and Fireworks was pretty much non-existent in my experience.
Yeah +1, at the start of my career (mid 2000s) all the web designs were done in Photoshop. I think this was true until 2010/11 at least, when I first encountered Axure being used for some design stuff. I’ve never used Fireworks and never saw it in the wild (UK, in case it was a regional thing)
Those days aren’t over. HN uses nested tables with 1x1 transparent spacer.gif images.
I like that HN’s design is timeless. It’s a shame people usually ignore it, or are critical of it.
The text is barely legible, and you can hardly ever click on the actual target you want (e.g. upvote vs downvote).
It's timeless in that it was never good to begin with, it is just actively malicious now for anyone using it from a touch interface.
> It's timeless in that it was never good to begin with
True but it shows that good design doesn't matter.
Also: Craigslist, Reddit, LinkedIn...the list goes on.
I was in web agencies since like 2002-2015, always got PSDs from either clients or internal designers
100%. I was always told to slice the PSD, fireworks never entered the conversation in the agency world I was a part of.
Sure, and also Illustrator sometimes, and Photoshop at other times. Some of the designers I know (very famous for their ui/web work) never touched vector components and just had a ton of layers in Photoshop and air/paintbrushed everything. Hence the meme...
I've even received designs in PowerPoint
Everyone used whatever they were familiar with regardless of the purpose of the application.
Many designers stuck with Photoshop sadly. Back when I did agency work it was absolutely normal to get PSDs of mockups.
I've seen the front end devs get PSD files as recently as 2021.
I think his point was made regardless of his mistake
I wouldn't even classify it as a mistake, just a difference in experience regardless of what Adobe's intentions were.
As someone who has done front-end development for both web and mobile devices for a very long time in the pre-Figma days I was handed a lot more designs that were mocked up in Photoshop than Fireworks.
It’s just one more example of people realizing that the code is the spec.
UX designers I encountered have mostly been tasked on ensuring consistency across the various product (A lot of devs are very cavalier about spacing and font sizes). Sometimes they proposed new flows and layouts, especially when the product needs a coat of paint.
So tools like Figma is nice in that regards as it's simpler to iterate on (From simple to hardest: Sketch on whiteboard|paper, Wireframe tools like Balsimiq, Figma|Sketch, css code) because it's pure fiddling with various properties. Figma has direct feedback while the code may require a compilation phase.
Yes, Figma is the de facto standard for how designers hand off a UI design to developers in large (and some small) companies.
It's kind of horrible, but I guess it's better than previous alternatives. But, it's not better than a tool that works with code directly and mostly automates away the tedium or translating a visual design into code. I haven't tried Claude Design, but I know I don't find Figma enjoyable (but I'm not much of a designer...I'm more comfortable with code than with pages and pages of options in a GUI).
I'm not sure about "without changing code" but I have definitely seen the believe that Figma represents something authoritative about the product instead of, say, the product being authoritative for itself.
Perhaps because I have a similar bio to yours, I am allergic to this view.
Replace the word figma with the word “specification” and it seems pretty reasonable to me. Same thing. It’s not a belief, it’s a process.
In a bigger company, yes, as it's required to make sure every engineer implements everything in the same way without differences in style over time.
As someone who spent quite some times these days to reverse the figma protocol[0] I can't agree more with
> Figma accidentally excluded themselves from the training data that would have made them relevant in the agentic era.
Their binary format is so much of a "let's reinvent everything" which I think come from the fact it's a tool you can use for web design, android app design, ios design and anything-you-want design that it became a jack of all trade and so mapping it to web is not a perfect 1:1 translation.
And for being useful to agent, any people who got to implement the figma from a UX guy know that even human can't know truly the intent of most figma design, so how a LLM could ? Common source of question that even the UX guy has no answer for:
I know that most of these question can be answered by props and autolayout, and I've been asking the 5 question above these days on a figma that had these but it's just that the UX guy is not that mythical beast that "know-how-to-use-figma-right"So I can't wait for these tools that are html behind to catch up, even more if we can have the prompt with it. (As a developer I never got to see the prompt the product manager made to the UX guy)
[0]https://github.com/allan-simon/figma-kiwi-protocol
Great article, the last couple of paragraphs made me laugh! I love the part about things not masquerading as something else and being honest about what they are.
I was wondering if PenPot (https://penpot.app) might be sitting pretty in this new agentic era, considering that they took the direction of designs being actual markup, unlike the canvas approach in fig - if that’s even something that interests them.
Wasn't the whole Penpot UI itself made in SVG? Or did they change that along the way?
I've worked on design tools for the last few years.
This article is a fundamental misunderstanding of both the design space, and figma as a company.
Just a few of my thoughts:
- Figma was always about building a successful company over a successful product. Figma started with a much more ambitious aspiration, and had the ability to deliver through talent like Evan Wallace. A lot of it started with showing how capable webgl was in the browser. And yet, a lot of things like 3d features don't exist because they had the awareness to really hone in and focus on building a specific thing that made them money because everybody in the company ended up with an expensive seat price.
- Seriously, Figma is a company that's about design tool second, and about getting a product that businesses use first. To that end, it's already succeeded through the IPO, subsequently, who knows what the market is going to look like. Figma having a war chest is in many ways much better than having a technically impressive demo that might evaporate.
- People at Figma, 100%, know everything in this article. And not just figma people, like anybody and everybody that's tried to build a design tool has had these thoughts. It's very obvious that ui/ux is the interesection of design/dev/pm. It's also very obvious that it should stick close to the source of truth, to something like code. - The problem is, that it's almost underselling it to say that it's MASSIVE challenge to execute on these ideas because of how easily it bleeds into building not just a design tool, but a coding, data management, architecture, etc. tool
- I could talk at length about all the challenges and potential solutions, but that's neither here nor there.
- On AI, I guess other people's guess is as good as mine, but my gut feeling is that while data is important, SOTA AI is generalist enough that the base models, the thinking they're able to do, is better than having a lot of custom data. Especially because ui design is front-facing - you can just scour the web in contrast to private financial documents, or legal documents for example.
This design tool space died a long time ago for me when InVision shut down and pivoted to a digital whiteboard. It’s a really difficult space.
But the fundamental problem is that it’s hard to get a design system right long-term, especially because it’s so intertwined with your code and whatever component library you use, which is a layer your designer will never touch. I don’t really see Claude Design fixing the fundamental Storybook hell of designing reusable and pretty components and layouts, but I don’t see Figma or any other tool solving it either.
What’s the solution? It feels like something that needs to be fixed more deeply at the component level.
The solution is an open, flexible, scriptable and drawable canvas where design and code co-exist in exact harmony. Design changes directly modify front-end code, and front-end code directly modifies design equivalently. I see the endgame as a model where designers and FEE's are co-owners and co-authors of the front-end with zero handoff.
Dreamweaver?
Microsoft Frontpage
Flash! Those were the days lol.
What if the approach isn't reusable, but instead is rebuildable? We are stuck in the mindset of creating components that we can grab and plug in to new designs. When we have a component that we like, why not ask the tool to create a markdown definition of it. Later on, when we're doing a new design where we would like to reuse that component, we tell the tool to read the markdown and use that whenever they need to use that component. I think the future will be much more flexible and interesting.
I don’t know what level of complexity you’ve seen in your software buildouts, but at anything “enterprise” scale, building your own components from scratch is a recipe for absolute disaster. There are so many nuances, especially with accessibility, and edge case bugs, that I would really strongly recommend against it. And by extension, I’d be against this approach.
Maybe you could make it work if everyone agrees on a base set of headless components to use, but we seem to be moving in the opposite direction with things like ShadCN.
> I don’t really see Claude Design fixing the fundamental Storybook hell of designing reusable and pretty components and layouts
FWIW Claude Code is decent at scaffolding those out if you have a good set of examples for it to work from.
But the argument is that is unneeded as we move forward as making changes and extracting things and such becomes basically "free". I'm not so convinced, but I do see the argument.
Recent and related:
Claude Design - https://news.ycombinator.com/item?id=47806725 - April 2026 (732 comments)
Some good points, but as a whole - I'm not sure if I agree. Sketch lost to Figma because of it's design tooling & multiplayer. Physical products still get designed before being constructed - I don't see that going away. If anything, I think Figma should stop trying to play both sides of the field and decide what it wants to be.
> Sketch lost to Figma because of it's design tooling & multiplayer.
Or maybe because you could just send a Figma link to anyone in your org and it opened in the browser vs having to tell them to download some Mac app and open a specific file that will get outdated over time.
Correct, though I believe the parent comment covered that under the broad interpretation of “multiplayer”
I tried yesterday for about an hour to have Claude design make me a simple logo (just the symbol) and didn’t get anywhere good. I’m sure for certain things like UI it’s great, and so is just Claude code, but this Claude Design thing very much to me feels like a demo and not a product. Maybe one day!
Claude Design is just a big opinionated prompt: https://www.lobsterpack.com/blog/claude-design-trenchcoat/. Among other things, it knows it isn't that great at drawing SVGs, so it won't try unless you force it to. For a logo, try drawing it with vanilla Claude Code as if it was a separate project: ask a "design agency" to ask you questions, answer them, then make a detailed brief of what you want to draw, then make it output an exact plan of what and where will it draw, lastly ask the chatbot to do the actual drawing using sub-agents for drawing individual components. Also add a "render it to a raster and make sure it looks right" step as well.
My prediction for every creator tool will be 30% deterministic software and the rest 70 is a long system prompt. This is the future.
[flagged]
Sure, the blog post is AI generated (I'm not a native English speaker, our bunch is often shy about our English language skills), yet the research I've done there is manual.
I found it interesting that (contrary to the popular opinion) there wasn't some magic, e.g. a novel model, happening with Claude Design, especially magic enough that Figma wouldn't be able to replicate if they felt like it.
Also, apparently human (not artificial) neurons were behind that huge prompt, very well aware of the limitations of the model, cheating here and there to make Design's outputs more impressive, making it "create a (design) plan" beforehand, i.e. all the stuff that we the common laymen could do ourselves with the same tools.
> Also, you certainly got some brass, linking an entirely AI generated article in a forum where extreme distaste is registered for entirely AI generated posts.
> How is your comment not downvoted to oblivion?
I'm sure there's a polite way to say things.
I heavily dislike LLM content, but if you read the content, it's actually got information of value.
> I'm sure there's a polite way to say things.
That was the polite way of saying things. The phrase "if you couldn't be bothered to write it why would anyone bother to read it" was a saying from usenet times.
The truth is it took the author less time to "write" that piece than you to read it. It's a blog. There's no deadline, and yet they couldn't take the time to actually type out their own thoughts.
> I heavily dislike LLM content, but if you read the content, it's actually got information of value.
If it was so valuable the author would have written it themselves.
Claude Design is very explicitly oriented towards product UI design. It's not trying to be a product that can make you a logo.
You should try the Arrow SVG model by Quiver, should be much better at that sort of thing since it's made for that.
Anthropic has no image generation models, right?
We've got an LLM using CSS and emojis and maybe pelicans riding bikes (SVGs).
Yes, they only do SVGs.
I'm actually glad they're focusing on code, and code adjacent tooling only.
The article makes a good point about how Figma's non-open data model is limiting their utility as the source of truth.
But I think it's part of a larger mistake Figma is making: they seem to have shifted to an extraction mindset too early, assuming they'd captured the market, right when the ground beneath them is starting to shift.
It's most visible in their pricing model evolution, which is now explicitly anti-collaboration. Figma used to be the obvious default because you could quickly share files with non-designers, so they could view and make small edits without fuss. Now that requires a paid "seat", along with a confusing mess of permission flows.
It's platform wide too. I taught a college design class recently, and had students sign up for Figma because it seemed archaic not to teach them to use it. Instead of just giving any ".edu" address a free account (like they used to) students are forced through a 3rd-party process of uploading transcripts to prove education status. A few of my students got rejected or ran into confusing errors, and never got access… Now I have to re-evaluate whether its worth using when teaching the class again. (And this is for a population with near-zero short-term purchasing power, but huge potential long-term value… why add barriers?)
This is such a weird self-inflicted wound for a collaboration platform to make. The big tools that won on collaboration (eg. Google Docs, GitHub) have understood that low-friction sharing is critical to becoming the default choice. And that being the default is a flywheel that drives adoption, both in users and in tooling.
It makes more sense if you see it through the lens of Figma trying to juice short-term numbers for their IPO. But it's sad to see because it had so much long-term potential.
> The big tools that won on collaboration (eg. Google Docs) have understood that low-friction sharing is critical to becoming the default choice.
Google docs is a heavily subsidized product and not representative.
Also tool pricing seems hard, but I can’t really get behind saying that a company should bait and switch with their pricing models harder.
Under that logic is a free trial a bait and switch? How about a 1-month free deal? How about what Adobe (and many others) do where they license to the school and students get it free until they graduate?
It seems like a really weird point to make, when you could just as easily argue that Figma giving their services for free to students is a gift that levels the playing field, by allowing students without means to gain experience with industry standard tools they might not have been exposed to otherwise.
It’s not zero-sum.
> Under that logic is a free trial a bait and switch? How about a 1-month free deal? How about what Adobe (and many others) do where they license to the school and students get it free until they graduate?
No. The key difference being transparency. You know when signing up for a free trial what the actual long term costs will be and can plan for it.
We might be talking about different things. I was mostly replying to this line from the OP:
> But I think it's part of a larger mistake Figma is making: they seem to have shifted to an extraction mindset too early
I’m not sure if this was just awkward wording that seems to condone these type of strategies.
All these loss leading, vendor lockin strategies have distorted markets heavily. Complex tools cost a lot of money to develop; and if another player is just going to burn piles of cash from elsewhere to undercut you, it becomes a game of capital allocation and not individual product quality/costs. It’s terrible for consumers and a big reason why even common chat apps are barely functional.
That's fair. I'm also heavily opposed to VC-funded, market-distorting behaviors and the later extraction-oriented outcomes they produce. In this case I was framing it in terms that might be more widely received by folks who aren't, and pointing out that, even if that was their mindset and goal, they were still making a mistake strategically.
But I appreciate the reminder to not cede ground in wording, thanks.
Watching the hive mind of the industry go almost overnight from inVision to Figma shows there's just no mote in this segment... people can leave just as quickly as they came, have no loyalty, and are all about fashion and vibes.
Not sure you can compare Invision to Figma. Invision wasn't a design tool like Figma is.
Design systems live in Figma. Not going to be so easy to migrate and Enterprise customers are moving slowly.
Front-end, UX, design, and product have become one role. The market is just realizing it slowly.
So your designers debug your React code now when the AI messes up?
In my opinion this should have always been the case. All designers should be able to code and do html/css. It's the medium of design.
I did graphic and motion design for 20+ years and been doing full stack dev for the last 6. It's very difficult to do both and excel at - especially in the frontend space where things move incredibly fast. As you try to excel at one, you'll feel left behind in the other. Very stressful.
> All designers should be able to code and do html/css. It's the medium of design.
So a fashion designer can mass produce clothing? So an interior designer can build a house?
This designer should has never held.
Fashion designers can, in general, work with fabric, yes. And an interior designer should probably have some idea of how to paint at the very least. To me with web design so much of what matters is encoded in the CSS and HTML that it is the final design product. Anything produced before is a sketch, a concept, but it's not a design.
The analogies you have offered aren't great.
For example designers and developers both use the computer as their primary medium of working. Their outputs resemble each other very closely, despite having a different underlying form.
Contrast that to the interior designer building a house, well those are different mediums. There is no efficiency gain from the interior designer designing the plan and also implementing it. Where as with a designer working in code there is one.
Fashion designers do indeed make clothing by hand, it's a very important part of their craft. This example disproves your stance.
> Fashion designers do indeed make clothing by hand, it's a very important part of their craft.
That’s not what I said. There’s the problem. I said mass produce.
HTML and CSS, sure, but modern frontend design is way more than that; it's a jungle out there.
React, Nextjs, Vue, Nuxt, and Angular are pretty much what AI is the very best at coding in my experience. Probably because they are all meant to build essentially the same thing with different curtains.
Ever seen a vibe-coded react app? It's astounding how well SOTA LLMs can produce good looking code in detail, but zoom out to the architectural or broader picture and it becomes an unholy mess.
It's like a masterpiece painted by an artist with their nose 5 inches from the canvas at all times.
I've been a developer for over 2 decades and I've been using AI in our react codebase for the past 3 months. Outside of some optimizations there's not much a designer couldn't debug through Claude Code. 90% of the industry is toast.
I want to be wrong because I'm watching the death of my entire career, but everything I've seen is pointing to this as an inevitability. We are shipping better and more secure code, and doing it easily twice as fast. Many development teams can be cut in half today with no reduction in output. I don't want to say it out loud at work yet, but we're actually producing too much.
I've been writing code for 50 years and it looks now that we have seen sunrise and are about to see sunset on humans writing code by hand.
Is that bad? Not to anyone who has managed dev teams and is familiar with the incredibly tortuous and painful business of trying to corral a bunch of humans with varying skill and enthusiasm levels to create software. We have tied ourselves in knots with things like Agile just trying to work around the fact that software development is so slow and arduous.
Many times back in the waterfall days I have written up design documents to kick off dev teams on multi-week or month projects. Now I could feed those into Claude Code and get results in days. This stuff is exciting beyond belief in just getting shit done.
This is a golden era for any established company with an existing customer base. My question to them would be "with Claude Code, why aren't you carving through that massive backlog of feature requests that has been building up over the years?".
A lot of people seem to look at this as job threatening, and it surely is for junior devs. But for companies that already have a strong senior talent bench, it's time to raise the ambition levels and ask not how many jobs can be shed, but instead just how fast and hard can we go now we have these new superpowers.
This is so context-dependent. Coding some generic crud app is indeed becoming more automated, but most of the stuff I end up building is just way outside the capabilities of current LLMs to accomplish without significant steering and gasps hand written code. Most of the stuff LLMs are good at ones hotting are the same things a non-coder could build with no-code platforms anyways. Which is great imo, it means we can utilise our skills and expertise on stuff that is more "cutting edge".
We're moving so fast that management can't keep up on reading what's happening, they're going to slow development down by cutting the massive cost of employing people. There just aren't enough features to justify the breakneck pace.
It's a golden era for business, but the industry will employ many fewer people.
AI is impressive but this same sea-change happened at least twice before - the era when computers went from being rooms full of women(354) to machines programmed in machine language(892) to those with screens, keyboards and even assemblers (assembly language, especially macro assemblers, were considered seriously high level at a time), to mid-level languages like C (considered needlessly complex and slow at one time, now considered barely above a macro assembler), to high-level languages like Java and even higher ones (arguably) like Rust.
Every one of those transitions has resulted in more programmers - though not necessarily the same programmers.
354: https://en.wikipedia.org/wiki/Computer_(occupation)
892: https://en.wikipedia.org/wiki/The_Story_of_Mel
But things really are different this time. Computers and software were nascent industries with lots of room to grow, lots of software to build in previous transitions. Today software and technology companies are the biggest in the world. Every industry uses software. Getting your web app, mobile app or game discovered is actually a huge problem today because we have so much software. There is not infinite demand for software, or for anything else, even if it seems that way in the early days.
The Olde Days were custom code for a business doing business things (only they could afford a computer, and some universities), then there was a Cambrian explosion of software sold by individuals or small developers to many (80s and 90s), then we've moved to large companies and SaaS.
I think we're about to cycle back to "custom code" except now it's for everyone, by AI - you don't need to find the to-do app of your dreams; you can code one for yourself in a fever-dream.
The era of "write Wolfenstein 3D in a few months and make millions" are gone, but they've been gone a long time already.
Or - there was a HN discussion on this half year or so ago - there's consolidation again, and there will be AI, but no code. Domain expert talks to the AI, perhaps with an expertised intermediary. AI spins up a whole new 'software platform' for the customer.. internally. Offers all the UI that is needed to work with it.. still 'in the cloud' i.e. in AI data centers. Customer happy, devs less happy.
AI isn't a technology that replaces programmers, it's a technology that replaces generic human beings. The manager of your agents will be an agent, too.
You don't see any way that this is different?
> Outside of some optimizations there's not much a designer couldn't debug through Claude Code. 90% of the industry is toast.
I've seen the "debugging" and "coding" that non-coding designers are attempting to vibe-code. 90% industry is definitely toast, but not the 90% you're thinking of. Most industry is going the way of Microsoft that cannot even display a start menu in under a second
I think the real question is which of the four roles is going to be the one that takes over. Probably people who were already UX-Engineers.
I would ask this: which is the worse failure mode —- design not quite right, or users can’t access the app?
On the other hand, teaching taste is quite hard, and is what people respond to and what designers learn.
Teaching programming is a bit of mostly solved problem, today anyway.
Realistically this doesn't mean all pure designers go away. Large orgs can have a small team that set the overall style guide and designs important pages, and the rest of the org just follows using AI to iterate.
That's the kind of question you will have to ask if you don't hire right. I get collapsing frontend/backend and PM/UI/UX but two then collapse code and product may be a bridge too far.
That’s what CEOs think lol. Let’s see if it pans out!
"I have an error when i click on the orange button, see screenshot. fix it."
Leading question, feel free to ask a more honest one.
All right, here's a statement: your designers won't even know when the code is wrong. Just because it compiles it doesn't mean it's fine. They lack code judgment in the same way your coders lack design judgment.
Thank you.
In response I suggest that the engineers using AI also lack code judgement (because they are not reading it either). I don't think questioning the AI use is the actual topic here, it is the shifting roles. Who says it's the designers that are taking the new meta-role? It's probably the FE's honestly.
The role shifting doesn't mean that it's the best path forward. I'm simply stating that it is happening.
It's very easy to know when code is wrong: it doesn't work the way it's expected to. So you explain to the AI what's wrong and the AI fixes it.
Your designers are going to be looking at the layout; they're not going to notice if it's slow, uses too much memory, is not maintainable, doesn't follow repo patterns, etc.
Do you think it is reasonable to expect a person with an arts degree to know this?
"This works but the app is slow, can you optimize it." I'm not even kidding, most of the time this is all that's needed. Repo patterns don't really matter because humans barely end up looking at the code.
We've had a customer send us a prototype of what they wanted built with AI, and they don't have a college degree in anything. It followed our codebase patterns without any prompting, included tests, and all we had to do was wire up the backend.
> Do you think it is reasonable to expect a person with an arts degree to know this?
There are plenty of people with arts degrees who know this, and PLENTY of dogshit engineers with CS degrees who don’t
> Do you think it is reasonable to expect a person with an arts degree
Of course it is.
The only people who think your fucking college degree determines your knowledge level and ability are teenagers and people who are so deeply untalented that it’s the only way they feel qualified.
This isn’t meant to be sarcastic: have you ever worked for a real company?
As we know from THERAC-25, etc., comprehensively verifying that code works the way it's expected to is not actually very easy - it's perhaps one of the hardest parts of building any system more complex than a toaster.
Thankfully the CRUD app that is being developed by some random startup is not likely to cause as much harm as the THERAC.
Depends on what it's doing.
Worth noting that you've slipped from "checking whether something works is easy" to "well, it's probably not as harmful as a very notable failure if it fucks up."
The bar lowers so quickly.
How is it a leading question?
They entailed scenario that isn't entailed by the person's claim.
i.e. The OP doesn't need to answer yes to their question for OP's claim to be true, yet their question pretends otherwise. (non sequitur)
>A leading question is a query that suggests the desired answer or puts words into a witness's mouth, often guiding them toward a "yes" or "no" response.
It was just restating what you already said; no need for this specious response.
Please quote me where I said 'my designers debug react code that AI messes up.'
I did not say anything of the sort.
See also: https://news.ycombinator.com/item?id=47819428
"Debug react code" => "Front-end"
"Designers" => "Design"
>Front-end, UX, design, and product have become one role.
Ok so, are your "designers" (now part of one role) not debugging react code? If they are then you mislabeled the question as leading to avoid discussing in good faith. If not, then you lied about the "one role" and it turns out that they haven't BECOME "one role".
This motte-and-bailey strategy is unproductive and disrespectful to the people you are addressing.
I miss the days of having a native desktop design app with a perpetual license.
What Figma achieved technically in the 2010s was amazing. Coded the app in C++ and then used WASM to deliver it as a multiplayer web app.
But now it's trying to be too many things. Why did they ever feel the need to add slides and this other stuff.
Their MCP is poor (sure, they'll improve it).
The app struggles with larger files and performance is sloppy.
And don't get me started trying to design data grid heavy apps.
And they could easily follow Adobe's lead. Enshittify and lock you out of your account whenever they feel it's necessary (remember what happened with Venezuelan Adobe users a few years ago?)
Either Penpot gets their act together and will become the opensource design canvas for open-weight AI models or we will see another open source solution that will fill this space.
> I miss the days of having a native desktop design app with a perpetual license.
You can go that route with Affinity Designer [1], owned by Canva, who partnered with Anthropic on Claude Design [2]:
We’ve loved collaborating with Anthropic over the past couple of years and share a deep focus on making complex things simple. At Canva, our mission has always been to empower the world to design, and that means bringing Canva to wherever ideas begin. We’re excited to build on our collaboration with Claude, making it seamless for people to bring ideas and drafts from Claude Design into Canva, where they instantly become fully editable and collaborative designs ready to refine, share, and publish.
[1]: https://www.affinity.studio
[2]: https://www.anthropic.com/news/claude-design-anthropic-labs
I have it, jumped on the affinity band wagon years ago after Adobe started their enshittification process.
After Canva bought Affinity, you now have to authenticate with your email from time to time when you launch the desktop app. Annoying and why do they do that?
Might go back to Affinity 2.
> Might go back to Affinity 2.
Sure, but they stopped updating Affinity 2; at some point, it's going to stop working unless you never upgrade your operating system.
By then I'm hoping we'll have an open source solution at the same quality and UX that Blender provides for 3D.
I got deeper into Figma than I ever had to before yesterday.
It turns out there’s no way to use Math in variables built in to the product. The most common plugin is 99 dollars. To add what is obviously mustache JS. To browser based software. It’s not good.
How does this compare to Google's Stitch? As opposed to Anthropic's, it's free largely due to the largesse of Google.
https://stitch.withgoogle.com/
Stitch has way more usage allowance, and it has been absolutely fantastic for some things, but it can get trapped in weird places where whatever you tell it to do it thinks it did it, but it didn't. It's like that Family Guy blinds meme:
https://tenor.com/search/family-guy-blinds-gifs
Wow, that produced pretty bad results (app). Claude design is much more useful than this but I've only spent around 20 minutes with each.
I feel like we're leaning way too much into the "vibe" aspect of using LLMs at the moment. There is definitely a good use case for LLM's here, but is just prompting your way into a design really the best method here? I feel like something in between Figma and Claude Design would give designers the control they want, but still removing the friction of going between design files and the code impl.
I tried Claude Design yesterday and fed it the UI of an app I am working on and what I had created already. I asked it to mock up 6 new "layout skins" using different colors, different icon and button placements, different vibes and it churned out 6 good designs with hi-res images plus Claude Code instructions and the ZIP file to boot. Didn't hit the usage, took about an hour. Did a really good overall and I liked the process and thinking structure and question asking.
As far as I'm aware, "source of truth" refers to data/code that drives the actual app, so Figma could never be a source of truth (Figma is a reference of what the app data/code is supposed to do). Saying Figma is a source of truth is like saying JIRA is a source of truth, which doesn't make any sense.
Excellent post. I share the author's sentiment which is essentially "to hell with Figma, at least fix Sketch". Been feeling very lonely in may hatred towards Figma, which is for a whole bunch of reasons (among others, it's an incredibly shitty, memory and CPU hungry Electron app that looks and feels worse than any more or less well designed web site), but now after reading this I realize the number of reasons has doubled.
It may look like a crappy Electron app, but Figma has a quite interesting architecture. The browser editor is developed in C++ and cross-compiled to JavaScript with emscripten. The rendering engine looks like its handling HTML, but it's actually rendering their own document format for cross-browser consistency. They have their own CRDT implementation to handle multi-user edits.
[0] https://www.madebyevan.com/figma/building-a-professional-des...
[1] https://www.madebyevan.com/figma/
[2] https://www.madebyevan.com/figma/how-figmas-multiplayer-tech...
I think my biggest question is who cares? What does having an interesting internal architecture have to do with the “its electron though” ideological attack.
It is made to perform much better than your typical electron app would. Saying electron-based == shitty is complete misunderstanding of the technology. Although i dislike Figma as much as the next guy, their app was in many ways very impressive. See Figma's cofounder old articles at https://madebyevan.com/figma/
(author of the post here) I cut a paragraph how Figma costs cuckoo bananas money for your entire team for the privilege of enduring this byzantine nightmare. And they paywall certain features, which you likely can't get authorization for, so you have to do more hacks on top of hacks on top of the “gold standard” practices I shared in the blog post. The price ramp is not gradual.
I think this is what kills them, not AI. I know 2 companies (enterprise level) who are migrating away from Atlassian atm just gets too costly.
man, I dont even use Figma for personal & side projects because its so expensive. I still occasionally fire up sketch or freehand it.
Figma is a work tool only and I'm disappointed by its MCP tooling which feels late and behind where it should be, I just feel forced to use Figma Make which stays in their walled garden without practical utility and connections to my actual codebases
> Figma invented its own primitives to make that work: components, styles, variables, props, and so on
Fireworks, Sketch, XD, Axure, etc all had these (or most of them) in some form before Figma even existed. Even illustrator, photoshop, etc have had the applicable ones for decades.
If you get to the post script it sounds like they are just pissed they didn't get hired by figma.
I promise I am fine lol, I actually had a really productive chat with their panel last year and found it wasn’t the right role for me anyway for some logistical reasons.
When you can control the model layer like Anthropic, you get more leverage over the traits of the persona, enough so that the system feels closer to havin consistent expert design judgment built-in that complements the 'truth-to-materials'.
Basic web development is completely over, and will be automated end to end, product, ux, design, and the code.
I have a complicated nextjs webapp, and I havent had to write front end code in six-nine months now.
If it’s used by < 1000 people, it’s not a complicated app
FedRAMP will be the death of me.
so like 90% of software?
Scaling and edge cases with real users are the difficulty. Feel like this isn’t even that controversial.
we agree, i just think you are overestimating software complexity for most businesses
If that is the case, 90% software was never lucrative
Congrats? You did what my manicurist could do 5 years ago with Wix.
Can someone please help me understand why people are obssessing over this as a Figma killer and not, more clearly, a shot at Replit, Lovable, etc.?
The AI app builders are part of the AI economy already. They are essentially re-selling tokens/compute. It's an existing horse race.
Bringing a Figma killer to the market is converting a conventional software sector into an AI one. So it's more disruptive.
Figma is going to regret not having sold to Adobe.
> "To Figma: I can see a world where this post does numbers in the Figma internal Slack. If that’s the case and you’re reading this from Figma: this wouldn’t have happened if you hired me last year when I was interviewing. Your loss, big dawg."
What a counterproductive way to end an otherwise good set of points. Gives the appearance of bitterness and a desire for vengeance.
Do you genuinely think that was earnest?
no real dog in the fight, and I don't even know if the OP's analysis is correct, but "they had a proprietary file format and got left behind because of it" always gives me a nice bit of schadenfreude.
Honestly, I never understood the move to create an artificial dichotomy between design and code with a heavy layer of tooling.
I suppose that a layout engine made sense in the context of Flash, and you saw the future of the web as a set of keyframe animations. But the notion that there's a lot of value in creating a very heavy, high-friction abstraction between the UI/UX and the platform it ultimately runs on was always going to be a loser.
In the end, it turns out we're all just web developers, regardless of your weapon of choice.
I was making a new brand file in Figma and was about to define all the variables and aliases, paths, all that. Took one look at it and just made the 8 colors I needed and went on with the design.
Oh no. Figma has variables and instances and it's hard to debug bad colors.
And here I am with Claude Code... That so far generated a 2000-line CSS file for a 7000-line app consisting of literally three web pages [1]. Where almost every single color, component, class and style is duplicated at least two times. Where custom classes are fighting with Tailwind classes (yes, there's also Tailwind ON TOP of custom CSS) that are fighting with inline hardcoded style= declarations.
Figma is definitely going to suffer the vibe-coded design slop-app from Anthropic.
[1] 7k lines are almost justified for the functionality in them, and I tried to keep an eye on the code. It's harder to keep an eye on CSS
Have had similar dramas with CSS. Opus/Sonnet seem to have far less taste and discipline in writing CSS - constantly they are trying to slam in changes with !important or inline styles rather than think through how to do it properly.
We can blame AI for slopcoding but it's just what we've been doing for decades now - who cares if it takes 9000 lines to do what in theory Linus and Knuth and Carmack could do in 3000? Our CPUs eat a million lines of code for breakfast and demand more.
Strange then that so many apps are barely usable on these powerful CPUs. Perhaps, CPUs can no longer demand more
LLMs tend to do better with component libraries like shadcn or daisy than writing raw CSS in my experience.
Figma should be worried
I hope the authors mom is not on the internet. Cursing in capslock. Good grief.
“ As product teams scaled and design needed to justify itself inside engineering orgs…”
What?
what are they talking about product teams needed to justify themselves? a good product guy's job is to talk to the users and figure out what to build. My job is to figure out HOW to make it happen. Neither side need to justify themselves. Good product people are vital to making sure engineers don't spend months building the wrong thing.
Where are they getting this absurd notion?
A lot of engineers find it difficult to conceive of product and design (and marketing, and management…) as actual skilled work. It’s all con artistry orbiting engineering.
Con artists do tend to be skilled.
[flagged]
[dead]
[dead]
[flagged]