I suspect the answer is typically "Yes, but putting this level of thought into any other area of development would have been more worthwhile".
I suspect the answer is typically "Yes, but putting this level of thought into any other area of development would have been more worthwhile".
Doing the deliberation, even if the answer ends up being "No" or "Not worth it", is a crucial part of UX design. Most people don't turn over those stones at all.
e.g. Anyone with spotty or slow internet has had the realization that most desktop software has never been tested on a connection slower or less reliable than localhost, and quality software where it rears its head immediately stands out.
It might seem like frivolous polish to be adaptive to the user's current connection speed, or it might give you a spot to put a smart variable knob that lets you build good software.
But I'd also point out that we're not used to writing software that cares much about the user's resources like remaining battery life. We just write our iOS app and then depend on iOS' battery-saving mode (global throttle). It's just not something we're used to thinking about, so it's easy to be dismissive.
> cares much about the user's resources like remaining battery life.
If you are in a position where you care about user resources then you would generally minimise how you use it, globally, in every case.
[I'd say that developers/product managers often do care about this, except that advertising is intentionally resource-greedy and will wreck any care given to this]
If a user runs out of battery before the end of the day, that is as much (if not more) about what happened at the start of the day as it is at the end.
I consider website design and development to _still_ be a craft that centers the end user, which suffers degradation of quality because of -- for lack of knowledge of a better name or phrase -- The Market.