4 ms·
Lack of care and attention. By developers who are pressured to keep sprint velocity up. By product owners who follow the ideal path. By designers who want sites
by pacifika 5y ago
Lack of care and attention. By developers who are pressured to keep sprint velocity up. By product owners who follow the ideal path. By designers who want sites to work like their mock-ups. By testers who don’t have enough time to test under specified features. By clients who are focused on reporting upwards and tracking business goals.
And by prioritising new learning experiences over boring reliable solutions.
- ricardobayes 5y agoWhat's wrong with wanting a site to look like a mockup?
- pacifika 5y agoTypically results in custom controls and working against the browser provided affordances
- ricardobayes 5y agoOf course, but I pride myself in able to create custom code and not just rely on some built-in stuff.
- ninkendo 5y agoWhy do you consider it a good thing to not use standard controls?
- usrbin 5y agoThe operative piece of the above post (to me) is "working _against_ the browser", not the existence of custom code per se. IME lots of problems with UI development have come (partly) from shoehorning tech to do something it's not meant to do, at the expense of speed, accessibility, and general usability. If the built-in thing doesn't do what you need, by all means build something that does, but it's worth keeping in mind that often the useful thing that end users actually need/want is the built-in thing.
- pjerem 5y agoNothing when mockups are iterable and editable by the team and when the designer is part of the team. A hell of useless code/new APIs/authorization issues just for no customer value but only discutable esthetics considerations when mockups are designed up front by some never available designer like they are some inviolable part of the specifications thus are enforced to the team.