[baisampayans]

While the speed of prototyping and even shipping to production has increased, I have been asking myself at what cost? I see a lot of garbage being shipped. Not because the code quality is bad, because execution has become cheap now. Ideas even though crap, are getting prototyped. Things which look effective on the surface, but has real UX problems in the underneath, are getting prioritised because someone in the room can talk better and enrol a leader to align with the idea. Good old user research or talking to users to validate ideas, iron out issues in the user flows has become too slow for the new process!!

[sarchertech]

The same thing happened when figma made it easier make prototypes that looked real and people stopped doing low fidelity mockups.

Everyone understands that a wireframe isn’t done yet and it’s easy to change at that phase.

[cm11]

This I believe is lowkey one of the core ways design broke at tech companies. There are other big ones, design (really product) is broke deeply, but once mockups became easy we stopped having discussions about information architecture and UX. We're talking about whether we think this looks nicer in blue or green. Happened before Figma, but Figma really grew it. The designers that tried to hold onto wireframes (or went to mockups, but tried to still have architecture discussions with them) fought an uphill battle—what were these guys even talking about? Even the other designers thought this.

Once mockups became easy, that little bit of vocational gate (as in gate-keeping) that was holding the wall for UX work went away. Execs and PMs could make decent looking rectangles, so designers became the people who could make especially nice looking rectangles. So you got a lot of product/UX designers that were much more visual designers. That matters, but the prior part was bigger in that the product processes and sprints often started to have little design in them at all. What was a two or three phase process was one, designer got requirements and made design—often they didn't even really get requirements before design. The design was the impetus for the requirements not the other way around.

This is what became standard: Leader would give something vague because they didn't have much idea or vision yet. They probably had something blue-sky-ish, meaning they had a bunch of ideas, which in amorphous abstract blue skies come together. Once those things appear side by side on paper/screen, they're off putting and contradicting. There are problems not just with how to fit the pieces, but with the pieces. The visual the designer provides triggers this. Designers being visual people can see a lot of that in their head beforehand, but won't be heard until they show "bad work." It's pretty common though to see the PM or the leader look at it and say it wasn't the vague requirements, it's that the designer didn't get it. Anyways, it's that design that then kicks off some assessment against reality. Then you have a little bit of a shot at real requirements starting to leak out.

[strix_varius]

I've noticed and felt this trend, but I haven't ever seen it put so well or really connected the dots with figma & pretty rectangles.

I remember discussions over relative easy of use of gray box wireframes... and that led to better products.

Now I've got designers vibing monstrosities that would have fit right in in the Flash era, I guess in order to draw even nicer rectangles now that execs than wave at AI and get a design.

[throwthrowuknow]

It’s a bit like having a 1:1 scale architectural model made of cardboard. You walk people through it and everything looks good on the surface so they start asking “when can we move in?” skipping all of the hidden engineering that still needs to be done and in some cases pressuring you to just waterproof the exterior so they can live in the model instead of building the real thing.

[cpinto]

I'll offer a different perspective on this: for years we (product/c-suite people) constantly got push back that giving a goal was no longer enough, we had to articulate the path to the goal in excruciating detail.

If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back.

There's still a way out of this mess though. All it takes is for folks to take shared ownership for hitting the goal and bring their expertise to the table to help draw the path to the goal.

[cm11]

I'd ground what I say in sharing your assessment of the observations or insight, but with a different takeaway.

  If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back.

Totally. And the takeaway is that we by and large should be doing this much more. That's what's needed from leaders. More vision, less delegation of vision. The stronger the vision, the less need for delegation anyway. There's something to be said about the difference between big picture and small picture, but at this point it's relatively intuitive that the big picture divorced from the small makes for worse big pictures. I'm not talking about how handing the big picture to the middle person tends to create interpretation/translation errors as well as execution errors to the extent the subordinate is less capable. Those factors are prominent and _in addition_ to the issue that the big picture is a worse big picture when these duties get stretched across two (or more) people. And thus, we should own these duties "vertically" and if needed reduce duties "horizontally".

Leaders (and companies) should be doing less horizontally. It runs the normal risk of stretching to thin, but their tenth and eleventh ideas are also filtered towards worse. Perhaps more fundamentally, the bar for adding a product/project should be higher. When the leader can "just" add another leader to take on the work—particularly one by nature with less power, ability, autonomy, and perhaps accountability—it's getting set up for a lower chance of success. In order: (1) the project probably shouldn't start at all; (2) if "started" at all, it shouldn't really look like starting, it should be a person validating for the leader who will then start it (many product teams pretend this is what they're doing); (3) if started, it makes quite a bit more sense for the higher (and likely more capable, but especially more empowered) leader to take on that project and hand the existing, stable, better trodded project where the team has institutional knowledge and support to the other leader.

In practice, sharing ownership is superficial, whether between leaders at different levels or between project team members. Why share? Own it or have someone else own it. Or if there isn't trust in the other person, cut it. If the leader doesn't have the time/interest and doesn't think they have someone capable of doing it, it should be as much a sign as a low quality idea.

It's not hard to find problems with middle managers—many are with the sorting that picks them, many are with the conditions of the middle. Structures and strategies to remove them, as you suggest, are a great idea. The main way is for the leaders, when faced with the scenario of "if I need to think hard", to not come away with "let's do it, but not me." We should be default no. Green lighting some work to validate it to a Yes works, but these are tasks such that the leader knows what kind of validation is needed—and is assigned to a person with those skills. An engineer, marketer, business analyst, user researcher, data scientist is going to validate things that a PM or a director have less or no training in. Leaders tend to appoint the latter though, sometimes for empire-building reasons, but I think more basically out of fear of control and legibility. Those are counter productive reasons if understandable.

[dzonga]

which is why I advocate for fat marker mockups [0].

very low fidelity - but describe ux flows.

[0]: https://basecamp.com/shapeup/1.3-chapter-04

[HlessClaudesman]

Yes, though this has been a problem long before Figma or AI. Photoshop enabled pretty pictures of what a website / app / service might look like, and then these often became set in stone.

One solution is to keep all mockups / prototypes strictly grey scale using bare bones vectors until every stakeholder has weighed in / signed off.

[wildrhythms]

"Signing off" doesn't exist because even after the thing is in a MVP stage the stakeholders will still want to change it

[sarchertech]

Oh yeah designers definitely did it with photoshop too but it took a lot more effort than sketching a wireframe.

[Fabricio20]

> Good old user research or talking to users to validate ideas, iron out issues in the user flows has become too slow for the new process

I haven't seen these in at least a decade in the industry!! Everywhere I used to work was always "PM wanted" or similar and the validation was always just QA making sure the thing works/does the bare minimum!!! Customer input was just for bugs.

I hope that with AI speeding up prototyping we can actually go the other way long term, where we go back to ACTUALLY talking to a customer and then quickly prototyping it to see if it is what they wanted. Figuring out what the customer wants remains the hardest part of software engineering, but at least right now its mainly because we just dont talk to the customer.

[Applejinx]

I'm in an industry where I can really see this, executed by honestly talented people able to interpret what the LLMs produce. It's bikeshedding hell. If you pursue every possible idea and get to implement all of them and it actually works, in the best possible scenario with no technical debt because you're able to stay on top of it (presumably in the window you have before you just burn out), you end up with all the ideas at once.

The project has tracked your imaginative state, and perhaps the states of your beta testers as they imagine things. It's a power armor suit tailored to specifically you. Nobody else will ever fit it because it's evolving too fast, all to implement your every whim.

I've seen this take 1.0 projects that are intentionally wildly scope-limited and great at that, and balloon until the project is the Everything Machine, doing everything but send email. I guess in the new era, every project expands until it becomes alive and devotes itself to your service… or at least, does its level best to be that for you and your beta team.

These things are not approachable. They're fever dreams, unparsable by outsiders. Discipline is lacking.

[jfim]

Prototypes aren't only for UX though, sometimes they're for exploring whether something is technically possible, or what are the unknown unknowns in a particular area.

For example, for personal projects, I've been wondering if it's possible to automatically create RSS feeds for pages that don't have them (yes), what are the challenges when building an archive-style page dumping system (need to dump CSSOM alongside getOuterHTML, remove/rewrite remote content, walk iframes, automate Chrome, scroll to load lazily loaded content, etc.), and if training a model to remove native ads from markdown coming from readability is possible (no, at least not with my current approach, but using the dom might work).

[dakolli]

Why wouldn't you use Archive Box?

https://github.com/archivebox/archivebox

[jfim]

A few reasons. Learning is one of them, since I don't normally deal much with browser and web related technologies, so it's a good way to learn more about them.

I also think there are a few interesting things you can explore that go beyond a simple carbon copy of what's on the Internet. Ideas that I've implemented are things like automatic extraction of audio tracks, transcription, and summarization, loading a page or podcast transcript into the context window of a LLM to discuss the arguments or factuality of the claims being made, automatically turning articles to reader view using readability/trafilatura, etc.

Directions I'd like to explore would be things like multimodal search ("that page I read six months ago about computer security with neon green text on a black background", or give me a list of fitness related pages I've read in the last twelve months), personal statistics (how is the mix of topics I've been reading about changing over time), annotating pages instead of just passively reading them, maybe even P2P archiving or discussions about pages, and all kinds of other things.

But installing archivebox would be easier indeed.

[theshrike79]

Mostly because I only need to get a site into an RSS feed, I don't need a massive archival solution to do that.

[abalashov]

I was today years old when I learned about this. Thank you!

[onion2k]

I see a lot of garbage being shipped.

One of the second order effects of AI collapsing the cost of building things is that product management is much more important now. A Product Owner/Manager who lacks the taste and insight (or data) to know what they should put in front of users and what they should just put in the bin will cause a company real harm, especially if the company moves to a "there's zero effort in building something, so we'll try everything!" model.

The only part that's really collapsed in effort is the translation from requirements into code. If you're using AI to generate requirements you're effectively building things based on what a 'random' requirements generator says. If that's as good as the requirements a Product Owner was writing then that person needs to improve.

[virgil_disgr4ce]

> Things which look effective on the surface, but has real UX problems in the underneath, are getting prioritised because someone in the room can talk better and enrol a leader to align with the idea

This has always existed. The ability to rapidly prototype has not changed it in any way.

An extremely experienced UX researcher once told me that, having been doing field research and user research for 3 decades now, every time it's a Fortune 500 company, after presenting mountains of research, it comes down to what color the CEO liked in the moment.

I don't understand the proclivity to latch onto whatever the new thing is and blame it for shitty decision-making that has existed as long as humans have existed.

[deterministic]

The same thing happens because of tools like the Unity/Unreal engine. Lots of low quality barely-more-than-a-demo "games" uploaded to steam. However those games rightly fail to make any decent $ so probably not a problem long term.

[tptacek]

Can you help me understand what the "cost" of other people producing garbage is? Prototypes are generally shop jigs. You'd feel weird gold-plating a stop block.

[godelski]

  > the "cost" of other people producing garbage is?

Sure can! It's a well known phenomena, won the researchers a Nobel, and explains a lot of the American economy and "lack of taste". The Market of Lemons[0].

Lemon Markets really require one important thing: at time of purchase, the average consumer is unable to differentiate the quality of the product.

Consumers are "rational"[1], so with "all other things being equal"[2], will make their purchases based on price. Therefore, the product that is cheaper but is also _in reality_ lower quality wins. This then pushes out any competition who is trying to differentiate their product through quality. Thus all products in that category decrease in quality and it becomes a race to the bottom, maximizing profits.

I want to stress that this doesn't require that the quality of products are distinguishable by experts, but only by the average consumer. You can probably look around at tech and notice this pretty quickly. The average consumer is not really tech literate[3]. They can't tell the difference. Hell, my parents don't even know the difference between the internet speeds from their ISP, even with the numbers displayed. The numbers mean nothing to them. Do they want 1GBps? 100 MBps? They don't know!

  > Prototypes are generally shop jigs

The problem is people are shipping prototypes. We may disagree what is a prototype and what is a shippable product, but that disagreement in itself is worth noting as part of the problem. I mean FFS we in the tech industry love selling things with the promise of future improvements. The last few iPhones shipped with the promise that they were going to get better with AI (did Apple intelligence really pan out? Did it pan out anywhere near what they promised? My Google Pixel phone still can't schedule a haircut for me or book a reservation at a restaurant, despite multiple promises).

[0] https://en.wikipedia.org/wiki/The_Market_for_Lemons

[1] Economics uses this term differently than what we use colloquially. Read "consumers make decisions based on the information available to them" not "consumers are geniuses and making perfect decisions"

[2] i.e. the only distinguishing purchase criteria is price

[3] If you think I'm wrong, please go spend a month outside Silicon Valley. Hell, go try a different country, and not in the major metro areas. We're nerds here. Every single person on HN is above average in this respect.

[tptacek]

The premise here is that people are selling these prototypes, and they are being bought. I mean, fine, that's bad, but when we discuss "prototypes", I assume uninformed cash transactions are off the table.

[godelski]

I gave the example of Apple and Google for a good reason. Because these big companies are selling products that don't even exist yet. You don't consider that selling prototypes? Fair, they're selling stuff that isn't even a prototype. I'm not sure that's any better.

Or maybe you're making a very different point, which I have entirely missed.

[joshuamorton]

> I gave the example of Apple and Google for a good reason. Because these big companies are selling products that don't even exist yet.

I guess I'm curious what you mean by this, I don't particularly see either of those companies doing this, certainly not in the way this article describes, and not really in any way that's impacted substantially by AI.

What "product that doesn't exist" is Apple selling? Google? Who is paying for it?

[godelski]

  > What "product that doesn't exist" is Apple selling? Google? Who is paying for it?

  >>> My Google Pixel phone still can't schedule a haircut for me or book a reservation at a restaurant, despite multiple promises

This example has been in how many Android announcements?

8 years ago: https://m.youtube.com/watch?v=D5VN56jQMWM

You're telling me you haven't seen the same promise for 8 years?

[totetsu]

Before if you had a crap idea you atleast had to face the social back-pressure of explaining it to someone at a local hackers meetup and trying to convince them to build it for you..

[jayd16]

Making software for users? Who even does that any more?

[socalgal2]

I'm having a hard time seeing your point. Faster iteration = easier to fix UX issues. That's all the LLM is providing here. Problems with UX = bad decisions. Those happen with or without LLMs.

[fHr]

Time saves on stupid shit management thinks works!

[jayd16]

But there's always more stupid shit to work on, so it just increases noise to signal in the app, no?

[speff]

Similar experience here, however my feeling is that this isn't necessarily a bad thing. Garbage being made is indicative of a gap in the currently-available tools. User research should shift towards analyzing these prototypes and enhancing existing tools to fill this need.