Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

LLMs are architected to aim toward the center of the bell curve of their training data. You shouldn't expect them to produce innovative ideas, but the upside is they also won't produce terrible ones.

The same applies to design. Most of the time, you get something that "doesn't suck", which is perfectly fine for projects where using a designer isn't worth it, like internal corporate pages. But consumer-facing pages require nuance to understand the client and their branding (which clients often struggle to articulate themselves), and that's not something current models can capture.



Internal corporate tooling can be greatly improved by promoting scheduled "water cooler chat on steroids" calls between engineers/designers/product/tpms/managers and the actual users.

What's nice is that these sessions bleed into everything. You don't need to look through users' eyes that many times to find great improvement in UX sensibilities.

Since scheduling is the biggest pain point here, I just built a scheduler and a signup form at work. Everyone who gets a session walks away with positive feedback, the company as a whole becomes more interconnected, and now I'm working to get more and more folk on board.

My goal is to unleash a whole flotilla of white collar workers who understand the value of talking to the users such that they too push for lightweight, no action item, scheduled sessions which becomes standard practice as part of our careers and we all end up with better software as a whole.


Tangent: Google keeps doing the same with GCP/Firebase/etc. Every year they launch a bunch of really well-crafted services that make it easy to build the most average kind of product in whatever area is trendy that year. Every year I am left intrigued but needing more to actually make use of them. The next year it's something else.

I guess this is primarily a business pattern. Or anti-pattern?


Assuming you mean cloud platforms in general, I don't even think it's that tangential. In fact it may cut to the heart of the matter: if React-over-REST-over-SQL-plus-some-background-jobs was all we needed, cloud platform innovation would've stopped at Heroku and Rails 20 years ago, and AI could probably make a run on replacing SWE jobs entirely.

But as it's played out, there are a ton of use cases that don't fit neatly into that model, and each year the cloud platforms offer new tools that fit some of those use cases. AI will probably be able to string together existing tools as IaaS providers offer them, perhaps without even involving an engineer, but for use cases that are still outside cloud platform offerings, seem like things that require some ingenuity and creativity that AI wouldn't be able to grok.


> the upside is they also won't produce terrible ones.

Design by committee is known to produce terrible designs. The best an LLM can do is to completely copy a common decent design.


Yeah, my experience is that when they do work they'll get the job done but the design is going to be unmaintainable garbage unless I force my own design on it.


I think it can be a false comfort to think of LLMs being trained to the center of the bell curve. I think it's closer to true that there's no real "average" (just like there isn't an "average" human) because there's just too many dimensions.

But what LLMs do, in the absence of better instructions, is expect that the user WANTS the most middling innocuous output. Which is very reasonable! It's not a lack of capability; it's a strong capability to fill in the gaps in its instructions.

The person who has a good intuition for design (visual, narrative, conversational) but can't articulate that as instructions will find themselves stuck. And unsurprisingly this is common, because having that vision and being able to communicate that vision to an LLM is not a well practiced skill. Instructing an LLM is a little like instructing a person... but only a little. You have to learn it. And I don't think as LLMs get better that this will magically fix itself, because it's not exactly an error, there's no "right" answer.

Which is to say: I think applying design to one's work with AI is possible, important, and seldom done.


I think this hits the nail on the head.

I've had great success using Claude to produce a new landing page which is much more stylish than something I would produce myself. It's also nowhere near the standard expected from a professional designer, but for a FOSS app, that's just fine with me :)


From time to time I look at the explore page of various AI design tools, and they are as corporate-depressing as I didn't expect them to be [1]. It's not even a bell curve. It feels like they are overindexed on bland corporate aesthetic. Getting them to output anything but a Linear clone is an exercise in frustration.

[1] https://x.com/dmitriid/status/1953750443248562431


Is there a reason you have two of each example in your post? Or did some tool produce literally exact designs from a single prompt? If so, what tool?


It's not two of each example. It's two screenshots. One from Lovable, one from v0 :)


Ahh I see. It's just lovable that has a bunch of exact duplicates. Thank you for the clarification!


I think the big issue with design is the ux to LLMs at the moment: it’s really hard to iterate on a design, see the output, make changes etc. I’ve had terrible luck getting good design from ChatGPT/Codex, but V0 is probably one of the most impressive AI UX experiences I’ve encountered — I often show it to non-technical friends who are ai skeptical.


LLMs don't produce ideas they implement them, anyone who is relying on LLM produced ideas basically doesn't matter the whole point is they make people who want to design interesting stuff have a lower barrier to entry of actually producing stuff.


"Implementing" a low-resolution idea is equivalent to "producing" a higher-resolution idea. It's turtles all the way down.

And ideas born without knowledge about their "implementation" are, by definition, quite low resolution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: