While this article makes a good point (don't say no just because you're lazy) I think it misses a more important one.<p>Time is incredibly important for projects operating with a schedule, especially if there's a fixed amount of development time (maybe the company runs out of money in six months).<p>As the implementor, it's up to you to judge how long something is going to take. Any time spent doing feature X, takes time away from tasks Y and Z. If the schedule is full(ish) then you need to have a discussion about tradeoffs. And quite often, even though X would be awesome, Y and Z are vital.
UX Designer, here. I think the key point in this post is to discuss the merits of any design suggestion. Designers aren't often aware of the effort it would take to implement a seemingly "tiny" enhancement. A lot of little tweaks add up to a lot of time, and designers need to be cognizant of that fact.<p>I always ask developers to tell me how much effort a change will take, and use those figures to temper my recommendations. If a tweak is really important, I'll push for it. If it's a "nice to have" we'll put it into the backlog, or push to the next version roadmap.
Kind of useless advice. What about when it doesn't take four minutes to code, and the designer is super-sure it is a good idea but then doesn't like the result, or wants you to endlessly tweak it? Should you just say "yes" then? That would be a good blog post.