[bfbf]

It’s amazing how many blank stares I get when I, as mobile engineer, tell stakeholders that we shouldn’t just implement some random interface idea they thought up in the shower and we instead need design input!

“But why can’t you just do it?” Because I recognise the importance of consistent UX and an IA that can actually be followed.

Just like developers, (proper) designers solve problems, an we need to stop asking them for faster bikes.

[zahlman]

> “But why can’t you just do it?”

The answer should be "because users will hate it and use a competing product that's better designed".

A shame that it isn't actually true any more.

[therealpygon]

It should be, but it isn’t. Hence the reason “why can’t you just do what we asked” can often be followed by “then we will find someone who will” in the end.

Pushback is valuable until it becomes obstinance.

If we all somehow had their same crystal ball to know for certain that “stupid shower ideas” won’t work because a specific developer thinks they are bad, there wouldn’t be much need for R&D ever again. I suspect this developer doesn’t have one either, or I’d certainly like to buy it.

[tuyiown]

Those people generally are not eager for feedback especially if it's even remotely perceived as negative or some kind of gatekeeping.

The only way to avoid getting furious about this is to deeply understand that you can't require people to be properly self-aware, especially because many many people that checks the expert boxes are very incompetent or inadequate, so they when the come up with their half bake ideas, they delegate the other to deliver contrarian proofs. It's exhausting.

[Findecanor]

How about: It's too easy for users to use the product wrong, leading to unnecessary tech support calls, and doing tech support costs us money.

[suzzer99]

An underrated senior engineer skill is saving stakeholders from their own worst impulses.

[abustamam]

Agreed, but I think it's underrated because the trait could also get someone fired or laid off.

[suzzer99]

Yeah you don't walk into the job doing it. But once your position is secure and you've built some stuff to where you can make changes in 5 minutes that might take someone else a day, then you can start pushing back on craziness.

There's also an art to how you do it. It's important to build up trust that you won't tell the client something is impossible or really hard just because you don't want to do it. You try to explain to them how much complexity this is going to add, how that will make it harder to add new features in the future, and most importantly offer some alternatives that get them 90% of what they're trying to do. Most clients will appreciate that approach IME, especially if you've already thrilled them a few times.

This is one of the reasons I'm not so worried about Claude taking my job in the immediate future. But I am still extremely worried about the industry as a whole and by extension the future of the middle class.

[abustamam]

Yeah I agree. I've worked with my boss in various capacities for the last ten years. When he says "can we do X" my answer is always like "we can do anything, the question is does the company want to allocate Y resources to get X done." Claude, being a yes-man, will always say "you're absolutely right!" to any idea you throw at it, not knowing (and, perhaps more crucially, not caring) if it's the right fit for your product/business.

I think part of the problem is that many engineers don't stick around long enough to build that rapport, which isn't a problem of AI in itself but is certainly exacerbated by it.

[joebates]

Too many people think being good at designing a UI primarily means knowing where to put something on a page.

[_moof]

Honestly, if we could even get that level of thought, it would be an improvement.

[jstanley]

There's a time and a place for it. If you already know exactly what the program needs to do, then sure, design a user interface. If you are still exploring the design space then it's better to try things out as quickly as possible even if the ui is rough.

[Enginerrrd]

The latter is an interesting mindset to advocate for. In almost every other engineering discipline, this would be frowned upon. I suspect wisdom could be gained by not discounting better forethought to be honest.

However, I really wonder how formula 1 teams manage their engineering concepts and driver UI/UX. They do some crazy experimental things, and they have high budgets, but they're often pulling off high-risk ideas on the very edge of feasibility. Every subtle iteration requires driver testing and feedback. I really wonder what processes they use to tie it all together. I suspect that they think about this quite diligently and dare I say even somewhat rigidly. I think it quite likely that the culture that led to the intense and detailed way they look at process for pit-stops and stuff carries over to the rest of their design processes, versioning, and iteration/testing.

[gmueckl]

Racing like in Formula 1 is extremely different from normal product design: each Formula 1 car has a user base of exactly 1: the driver that is going to use it. Not even the cars from the same team are identical for that reason. The driver can basically dictate the UX design because there is never any friction with other users.

Also, turnaround times from idea to final product can be insane at that level. These teams often have to accomplish in days what normally takes months. But they can pull it off by having every step of the design and manufacturing process in house.

[ivan_gammel]

There exist other ways to do the research. „Try things out“ is often not just a signal of „we don‘t know what to do“, but also a signal of „we have no idea how to properly measure the outcomes of things we try“.

[abustamam]

I'm the lead for an internal tool for a non-technical team. We iterate so quickly that the team we're building it for was like "can you guys stop changing things so quickly? We can't keep up with where anything is." which was a fair assessment.

[bfbf]

But that’s the point, no? Prototyping is useful but beyond a proof of concept, you still need a suitable user interface. I have no problems if there’s a rationale behind UI changes, but often we have stakeholders telling us to do something inconsistent just so their pet project can be presented to the user. That’s not design.