It's been thus, nigh on two decades now.
Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"
Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"
Don't."
-- https://web.archive.org/web/20021009021738/http://www.iarchi...
Problem is, most leadership doesn’t care about usability unless it affects marketability, which is less and less likely as people (users) become more comfortable with and accustomed to hopping between needlessly proprietary workflows and abstraction of crucial processes.* Often (usually?) designers also don’t, to be sure, but those like myself who do care are, like devs, up against unreasonable speed demands and interruptions that make it difficult to do our best, most thoughtful work. And though it may seem like design is higher up the totem pole, perhaps because it’s usually upriver from dev, in my experience, most companies see designers as whiny graphics monkeys, just as they may see devs as whiny code monkeys.+
It’s significantly more difficult and time-consuming to design novel functions and flows that conform to or complement existing standards than it is to draft a new system that need only make internal sense and may wantonly disregard the environment around it. This is why people like Electron, right? This is why people liked the internal combustion engine.
* I’d like to see a study on how this kind of acontextualization of work tasks might exacerbate burnout.
+ How many companies are actually defined by great design these days (versus, say, great functionality)? Not even Apple seems to care about that anymore, as they seem eager outpace their software with their hardware, rather than creating any iconic or lasting designs. As “product design” has evolved to include software products, the discipline and its output have become just as mutable, and therefor disposable, and therefor ‘not worth’ the effort necessary to make good things, let alone great things.
We created this problem ourselves by not having the tools to meet designer needs while doing it right. Pontificating about how they should just change their notion of right misses it completely.
I don’t think telling developers “just do it right” is a scalable solution, the platform has to make the least effort path the one that works best.
Use the system tools. But make the look of the system tools customizable.
System tool. Customizable look.
That's what should be available. But even today you can't consistently change something as simple as a scroll bar or a checkbox.
Which, even worse, are by default styled differently on different browsers.
Separating look&feel from functionality isn't that easy. In any kind of UX, they are bound to various degrees, depending on the use-case.
So if they're _exactly_ getting the point, they're pretty unobservant.
There already is no consistency.
https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio...
Everyone, literally everyone is running their own thing. Name me big company that doesn't roll their own design system.
Preaching purism really doesn't help anyone, let's just accept reality as it is, and stop chasing some utopian dreams that just won't ever materialize (and if only because it would make a lot of jobs and professions useless, overnight, and there's too much inertia for that to happen).
We will never live in a world where an abstract concept like a checkbox can have an 'assigned' specific visual affordance that doesn't allow for adjustments. Such thinking is stuck in the past and won't allow for new/better UI paradigms.
To think that there's no room for variation in the design of form controls, given the broader context of a design system for app, is just a lack of imagination. I guarantee you that the people who design the operating system form controls (which change every couple years) have all sorts of ideas, and they end putting out one possible, relatively minimal option from many good designs they considered.
> Pontificating about how they should just change their notion of right misses it completely.
The ask isn't to change their notion of right, but to understand that (yes, sadly) there is a tradeoff between "usable but ugly system components" and "pretty but janky" bespoke components, and they're making the wrong choice.
If what feels like the vast majority of them are making the same "wrong" choice, we should probably think about ways to make that choice more "right", because clearly, the current approach isn't working
At some point we have to climb out of the trenches and introspect why the most treaded path in web design is the one with the rickety bridge and spike pits when we the software engineers are the ones who lay the bricks.
If youve only designed/“Ideated” for iOS or Android, you have no business designing for web. Entirely different platform with different capabilities.
Embrace reality and build simple effective products. Literally no one gives a shit about the arrows on your carousel or the border radius animation on a button. I just want to scroll and click and open new tabs.
And lest it be overlooked, the appearance of those widgets themselves, is a feature. They are easily identifiable by users of that platform as being something they can interact with and expect a predictable set of outcomes.
Would it be great if everyone on the frontend could get together and agree what the native-to-browser widgets should look like and how they might be customized? Yes. Would the three warring browser manufacturers change their platforms to make web development easier and lighter for everyone, at the cost of platform uniqueness? No.
This would not be great at all. I want widgets on web pages to look like macOS system widgets on macOS, and to look like Windows system widgets on Windows. I want designers to lose the notion that it is their system style, and respect the fact that the browser is _my_ user agent, and therefore must respect _my_ preferences.