Most of the time, I'd argue that you can't really say 'No' at all. Not if you want a happy client. If you do say no, then you'll just end up delivering an end product that isn't exactly what the client wanted and didn't have that feature they requested. I can't imagine any situation where that results in a happy client.
So what do you do? I say: Get the client to say 'No' for you.
Getting people to understand the trade-offs and sacrifices for what they might consider a "quick 'n easy" feature is the name of the game here. You've got to flesh out all the assumptions that they have when making such a request so that they understand what the impact is on schedule, budget, and code.
But what they still don't understand is why Projects X, Y, and Z will have to be pushed back for 2 weeks or why Joe and Mary will have to pulled away for 3 weeks just to do this "quick", "simple" thing. At this point, what I usually do is spec out the entire feature (front-loading all the mockups, copywriting, etc) on the spot or in a meeting immediately following. The reasoning is that "If you want this feature tomorrow, then it has to be designed today." And well, practically speaking, you can't implement it by tomorrow if you don't know what you need to do yet anyway and, worse still, you'll build the wrong thing if you don't at least discuss it in some detail with your client first.
If the feature isn't important enough to spec out in detail now, it's not important enough to be done by tomorrow.
In my experience as a solo webdev freelancer (so take it for what it's worth), clients usually see my point and give in when they realize that we're trying to compress about a week's worth of back and forth emails, phone calls, and let-this-idea-sink-in time into about an hour--sometimes even realizing that they don't really know yet what they want.
So what do you do? I say: Get the client to say 'No' for you.
Getting people to understand the trade-offs and sacrifices for what they might consider a "quick 'n easy" feature is the name of the game here. You've got to flesh out all the assumptions that they have when making such a request so that they understand what the impact is on schedule, budget, and code.
But what they still don't understand is why Projects X, Y, and Z will have to be pushed back for 2 weeks or why Joe and Mary will have to pulled away for 3 weeks just to do this "quick", "simple" thing. At this point, what I usually do is spec out the entire feature (front-loading all the mockups, copywriting, etc) on the spot or in a meeting immediately following. The reasoning is that "If you want this feature tomorrow, then it has to be designed today." And well, practically speaking, you can't implement it by tomorrow if you don't know what you need to do yet anyway and, worse still, you'll build the wrong thing if you don't at least discuss it in some detail with your client first.
If the feature isn't important enough to spec out in detail now, it's not important enough to be done by tomorrow.
In my experience as a solo webdev freelancer (so take it for what it's worth), clients usually see my point and give in when they realize that we're trying to compress about a week's worth of back and forth emails, phone calls, and let-this-idea-sink-in time into about an hour--sometimes even realizing that they don't really know yet what they want.