It's because they're designing it in Figma or Sketch, and of course infinite scrolling doesn't work in Figma and Sketch. If you don't predict this problem intuitively, you won't catch it until it's been implemented.
Ideally, there is a QA pass on staging, involving the designer, in which more than "does this feature work as written in the ticket" is the question you try to answer before releasing the feature. Many teams don't do this, and the blame for that lies with different people in different organizations I've worked in.
But developers often sneeringly deride designers for not catching things like this — "you had one job, lol" — but the sad truth is that there's no testing suite to help designers catch stupid mistakes. Speaking practically, the unit tester for a design is often the developer who tries to build it. Imagine what your interpreter or compiler or testing framework would say about your intelligence if it could talk!
I've encountered pages like that and wondered if the ux devs did it for that express purpose... last time I saw it, I was looking for some legal info (copyright/privacy or something); a dark pattern indeed.
A professional medical doctor will make more medical mistakes than I will.
Let us try our best to treat them charitably, forgive the mistakes we see, and provide input to help them do their work even better!
I had success working with Design/UX or any other specialists acknowledging that they spent more time thinking about it than I have, and that, of course, they will be the final decision makers on whether to accept or reject any inputs I give, before providing any feedback or ideas I have. Also, taking the attitude, not of "Let me teach you X", but of "Teach me whether you considered X and, if you have, why you haven't tried X yet".
You probably misunderstood: gp won't make mistakes in a medical field because he's not a medical professional, so he won't do anything in the medical field.
The same sometimes applies to designers and developers: if developers don't design, then of course they won't make bad designs.
The gist of it all is: don't ridicule people for mistakes, even if they're in their supposed field of expertise. Just let them know they've made a mistake if you see one.
I've witnessed it multiple times during our UI/UX meetings that the engineers present there (representatives of the engineering team are invited too, to tell whether it's going to work with our current architecture/deadlines etc.) often give more insightful feedback/criticism on UX than the other members on the UI/UX team (why the stuff looks crappy, makes no sense, hard to use etc.)
I think the reason is, devs view a design from the perspective of a simple user, they see it with fresh eyes, while the UI/UX team probably spent too much time tweaking the design to the point they got used to it and all its quirks and stopped seeing anything wrong with it.
It’s not just designers. I’ve given up suggesting style improvements because the boss comes back with “no user complained about it yet” when my suggestion is to use less crappy color. Who is going to complain about a color? Smh
Ideally, there is a QA pass on staging, involving the designer, in which more than "does this feature work as written in the ticket" is the question you try to answer before releasing the feature. Many teams don't do this, and the blame for that lies with different people in different organizations I've worked in.
But developers often sneeringly deride designers for not catching things like this — "you had one job, lol" — but the sad truth is that there's no testing suite to help designers catch stupid mistakes. Speaking practically, the unit tester for a design is often the developer who tries to build it. Imagine what your interpreter or compiler or testing framework would say about your intelligence if it could talk!