HN tends to be more developer focused but I suspect most of these horrendous type decisions aren't made by random dev, and random dev isn't in a position to stop it.
Many years ago I once worked at a place where a CRM app had "special instructions" and at one point management was so upset about people not following them 100% of the time they were considering "make them blink" so the drones wouldn't miss them ... thankfully the blink tag had been deprecated. These instructions were sometimes several paragraphs long ... and they wanted them to blink...
Oh, I have worked as a freelance graphic designer once. Design is one of those fields where customer interaction can absolutely destroy any fun the profession would otherwise contain: everybody (and I mean everybody) has an opinion on design. The problem is, that many of those opinions are as uninformed as they are held strongly.
"Just make everything bigger" is one of those opinions. At the point where you have to explain your customer how basic perception works, how you cannot make everything equally important without sacrificing something — this is the point where you lost.
I'm not so sure. Most of the web devs I have worked with over the years haven't been overly thoughtful regards UX. I'd even go as far to say that it's the least considered aspect of their process. "Not my job" mentality. Tho probably says more about the nature of my experience than anything else.
I've done this, but it can be hard. Some designers can be very protective of their design, and you have to fight entire battles for something like "this white header text on a light-grey background image is almost unreadable, so I tweaked the colour a bit and added a text shadow" and other really basic no-brainers like that.
I don't even have very strong opinions about design; anything is fine with me. The only part I really do have a strong opinion on is "it should be readable", and enforcing only that has been very tiresome at times.
I totally agree it's not always easy. But again I think with something like this it's about savvy communication rather than enforcement. How do you articulate a challenge to a designer that respects their role in the process? Contrast is easy, there's defined standards you can defer to. But for sure, it gets tricky where it's just a difference of opinion or priorities.
Regardless, just going ahead and changing the design is probably the nuclear option. It's only going to start a war. Put the shoe on the other foot: consider same designer dropping a 2008 era jQuery snippet into your carefully constructed page to resolve an issue in the build. Not fun for anyone.
Edit: I should add, I'm basing all of this on personal experience. Appreciate some situations just suck and you have to get on with it.
No doubt. But this sounds like a communication problem between two stubborn parties. If someone demands a ridiculous feature and is immune to rational compromise, then sure .. state your objection, build the feature and send an invoice. In my experience this is rarely the situation. More often its a case of the real issue not being clearly articulated, a lack of will to compromise on behalf of the implementer (as much as the annoying, ignorant client), and a general cynicism from both parties as to the role of the other.
For sure, but then this isn't so much about "deciding" as it's about critical implementation and basic communication. Again this is in my personal experience, but when features like this make it through it's almost always due to an oversight on behalf of multiple teams .. or severe cynicism from a dev.
In my experience it has almost always been devs who don’t really use what they’re developing. “Alert sounds don’t stop if alert panel is open when new alert comes in” is only something a heavy user will notice. A dev might trigger an alert, but never think of weird edge cases like this.
There are applications I use where if the dev actually had to use what they made regularly, they would start implementing changes that get rid of the tedium. That’s also why in that CRM case I would really be pushing to have the opportunity to work as an actual user a few hours a week to really get a sense of how it works and what they really needed from those special instructions.
That's where I'm at... but of course we don't have footers of doom, because we won't. So that's kinda moot as far as all the internet "don't do this" proclamations go.
I suspect the really bad stuff comes from places other than the developers.
A lot of UIs designed by developers without going through a real design phase end up only making sense if you already have a mental model that more or less matches how the software works under the hood—the easiest UI to implement is usually one that doesn't provide any abstraction over the inner workings. So you end up with a steep learning curve, but software that is usable once you understand it. That's entirely different from a software feature whose design makes it literally impossible to use.
The most common thing is nobody owns the decision. Someone (an engineer) chose an implementation detail and nobody thought about it any sooner. Then these things pile up in interesting ways over time. Rarely is it "the engineers hands were tied". Barely anybody is telling the engineer what to do in the first place, mostly due to a lack of proper requirement gathering since the software is always considered to be "shipped late" in perpetuity by the business, so who has time to properly plan?
HN tends to be more developer focused but I suspect most of these horrendous type decisions aren't made by random dev, and random dev isn't in a position to stop it.
Many years ago I once worked at a place where a CRM app had "special instructions" and at one point management was so upset about people not following them 100% of the time they were considering "make them blink" so the drones wouldn't miss them ... thankfully the blink tag had been deprecated. These instructions were sometimes several paragraphs long ... and they wanted them to blink...