Part of this isn't designers, but "stakeholders" and managers and such wanting to put their stamp on things. They often do this through design, I suppose becaus

Part of this isn't designers, but "stakeholders" and managers and such wanting to put their stamp on things. They often do this through design, I suppose because you can show anyone a screenshot in a powerpoint and they can appreciate it, but you can't show everyone a program logic flow chart and have them appreciate it. One way to push back, if you use anything like story points for estimation and scoping, is to point low-design and high-design options separately, for any elements where design choices may have a major effect on that. "This is a 5-point feature with a basic button with the correct brand colors and a spinner for busy state—but a 13-point feature with what's presented in the designs, including a bouncing hover animation and the button morphing into the company logo as its busy-state et c." Part of the problem is the cost of design on the development process, not just making initial mockups, is often ignored or not correctly accounted for. If you make it explicit, lots of times it turns out a simpler version (which is going to be better for users anyway, 90% of the time—but being good for the users isn't the reason for a lot of UI design, see: constant user-hostile but flashy redesigns across the industry) is in fact acceptable if it means you can fit another feature or two in a given sprint. "We can come back and do the fancier styling & behavior later when we have less feature development to do" but then, as with most things that get deferred, you never will, which is for the best.