I think there’s a lot to be said for leaving details out if you’ve not thought about them enough to say something constructive about why they work as they do. I think it’s actively dangerous to plonk a canned interaction/designed component on the canvass and then not think about it again until it becomes accepted by force of simple inertia. In other words “make your life easier if you don’t care about the details” turns into plain bad design further down the line.
It’s hard to say how corrosive this phenomenon is when looking at finished stuff in the wild, but I think I can see it quite often. Things like poor usability of tree menus, unnecessary pagination … and date pickers that don’t apply very well to the time frames users are expected to navigate. I witnessed the following twice in user research on a live site a few of years ago, to illustrate the latter example:
When choosing a date on which to book a flight, they selected the date picker, which only showed a single calendar. The desired flight date was early in the next month, so they needed to progress to that but hit the “year” increment instead. After a partial recovery to select the correct month, they ended up booking a (very cheap!) flight 12 months after they actually wanted to travel.
The date picker looked very much like it came from a standard UI library.
All this is also why I think the notion of obeying “design patterns” is probably better re-cast as avoiding anti-patterns instead.
… and we’re forked for sure.